retsof

No .SQZ? Eyeeewwww. Did you previously send a free GEDCOM to the free rootsweb site? It would be possible to import a GEDCOM to an empty project, but it wouldn't be as clean as from a TMG backup, of course. What do you mean by "other locations"? Now you know. The most important location is a backup file. Did you have an exhibit or text memo in MS Word or Word Perfect or something? I'm not sure why TMG would even care. Mine doesn't. (The preference does indicate whether you want to use the WORD spell checker. Perhaps that's it.) Other than that, it would be possible to do a copy/paste, one field at a time.

How long has it been since a backup? If it is recent, simply restore from that. The system will reindex. Preanswer: V7 may or may not be different. I haven't had this problem: In TMG V6 it was possible to delete ALL of the indexes, and run a reindex.

That's fine, except that second site doesn't have a GEDCOM download option, does it? (On the other hand, I may not have looked too hard. I haven't seen that on existing websites created with SS.)

I haven't tried messing with exhibits yet. Another test might be to set up a person with a FAKE exhibit, and renumber the person. See whether the reference exhibit moves with him. If so, renumbering the whole dataset would then be no problem. There might also be differences between internal and external exhibits. Current thinking is to use external exhibits to keep the backup dataset size small.

If the specific ID number is not important, you can always do a tools/renumber people/renumber people in the selected dataset to condense all ID numbers and eliminate the gaps.

Don't backup/restore directly to/from the memory stick. The temporary work files will overwhelm the small device. Backup normally on the desktop. Copy the desktop .sqz backup to the memory stick and copy that to a .sqz. on the laptop restore laptop from the .sqz on the laptop. Caution. If you make any updates on the laptop, you will need to do the same thing in the opposite direction or enter the same change on the desktop to keep things in sync.

What would happen if you write the path the same way we HTMLers do when we want an embedded ampersand in the webpage link, as C:\Users\user&user\AppData\Local\VirtualStore\Program Files\GenSmarts ? & is the escape character amp is the mnenomic for & ; closes it

Microsoft wanted files in certain locations for Vista, so TMG V7 puts files in those locations, in the path of the username by design. They end up being more scattered than TMG V6. If you are still using Win XP, it doesn't really care, so you could override program preferences to put them where you are used to. If you are running Vista, then all bets are off. More experience is needed on whether to advise any changes. I have Win XP here. The only one I cared about myself was the backup file, so I changed the preference to another location on my second hard drive location for redundancy.

It's not just the size of the file that misleads one to think that the flash drive is large enough to hold it. The backup process must make a lot of temporary workspace in the backup location to perform the compress and backup, and that simply overwhelms the small flash drives. Use those for only TRANSFER of .SQZ files (or any file) from one computer to another.

The essence of it is the same. I wouldn't worry about it too much. Once you have absorbed the book you can investigate some new features. Some users have also written some newer website tips that would help. Here's one that comes to mind: http://tmg.reigelridge.com V7 mainly had some changes for Vista execution and some speed enhancements. There are always bug fixes over the years. I started myself with V6, but there is a change log on the main site to explain the evolution of the product.

I haven't seen any responses so .... if worse comes to worse, you might have to restore the project from a previous backup. The database may have become corrupted.

none of this has changed. I told them to follow this thread.

Yes, I have optimized/validated/optimized, and backed up/restored/reindexed, with no difference in the report. This is a clean database in other respects with less than 20 records added since the utilities, and V7 is running faster on it than on V6. A V6 validation took 8 hours. The V7 validation was done in less than 5.5 hours on the same computer. I'm getting ready to build a new one for this and other reasons. It still takes about a workday's length of time to complete the cycle. The report problems were showing before the last series of utilites, but nothing changed because of them being running again. To compare the 216 person compressed pedigree report, I'll run a regular pedigree report starting at the same place, with the 10 generation setting. It has 248 persons, as it should have. The complete pedigree is there, with no unknown persons as in the other report. That one was the 4 generations per page setting. The 5 generations per page shows 254 people, so the splits between pages could be slightly different. Why does the little gray processing box say "14 generations" when I have only asked for 10? It may be filling out the number on the page, I suppose. I looked at the 4 generations per page setting again. It supplied 11 generations for 248 persons. Here's something. The 10 generation ahnentafel report also shows the 216 person count. The same persons that caused the problem in the compressed pedigree report were changed to "an unknown person". I'll try another setting. I have a focus group for ancestors of me. I'll run the 10 generation compressed pedigree report again. 216 persons. I added the "unknown parents" setting to the compressed pedigree report and got 355 people with the problem records remaining. It must be more of an automatic thing that is done at the report level, since no database intervention is required. Each "unknown person" now has two "unknown parents", so the unknown persons are being treated as database records with the real parents ignored, as before. The thing that is odd is that the error is selective with the same database records. The pedigree report runs correctly. The ahnentafel and pedigree compressed reports have that unknown person thing with the same unknown persons in each case. It's not all or nothing. I had previously sent a message to tech support to tell them to follow this thread. I discussed it in the message group, but a lengthy test process is easier to monitor here. I'm not dead in the water, as I can use the pedigree report for accuracy, and more room to scribble. At least my B&W laser printer will print on both sides automatically, so it's not as much of a paper penalty. I might even try the 2 sheets on one page setting there. (4 sheets on one double sided page). Well, no, since TMG isn't using a standard windows printer setup in the file/print setup. Even if I set the printer to the real one, I don't see the duplex options. Once I see the print preview with the ribbon tab, if I hit the printer icon, that's it. It prints. Would the PDF printer be preferable? Upon hitting the install PDF printer button, it went through its thing and said to launch "install -u". Where?

Yes. No threshhold. Include blank surety. I have not changed these settings at all while I was adding records, running the report, deleting the records, running the report, changing the subject person, etc. and running several more reports.

I'm still looking for a reason. If the newness of V7 records isn't the pattern, I must look some more. I hadn't output to any external, but was looking at the print preview file. For the ones that didn't work, I got 1 person, unknown, regardless of the number of actual ancestors. There was a special intervention by tech to clean up this particular .SQZ file for V7 since the regular conversion had a lot of problems and did not complete. Everything else I have found so far works with no problems at all, even on the same records. I was just wondering whether there was some internal Foxeriffic difference between a converted record and a new one. The project currently has nearly 671,000 names in the picklist and 485,000 IDs. There ARE a lot of duplicates from overlapping GEDCOM imports that are slowly being combined as time permits. Newer imports are being done in other projects with finer control and more preprocessing cleanup. Here's something else. I am still suspicious about the pattern. I changed the subject person to someone I know exists, ME in this case, #1 in this database. I cut the search limit to 10 generations to save time. The report appears at first glance to run correctly and has 216 persons, but I see two more recently entered ancestor records at the top of the chains for "AN UNKNOWN PERSON". The records exist with real names, and has even more ancestors, totally ignored. Whenever a suspect record is encountered, any ancestors are omitted and the name is changed to "AN UNKNOWN PERSON". Other older records at the top of their chains remain at the top, with no extra unknown persons added. AN UNKNOWN PERSON becomes the top of the chain. I'll try inserting a fake generation with an extra person between a real father and son and change the fake to the primary father. Let's see what that does .... I added an artificial father above my paternal grandfather and made his father my great-grandfather. Yes, the pattern I have found is totally repeatable. "fake foster" is changed to "AN UNKNOWN PERSON" and becomes the new top of the chain, instead of the several more generations that were previously there. There are now only 186 persons in the same report, instead of 216. Try it to the print preview... This is an AMD 2.4GHz computer with Win XP and 3 GB memory and a 200 Gb primary hard drive. The secondary 300 Gb hard drive is used for the .SQZ backups. Now, I will add a "fake mother" for my paternal grandfather, connected to my great-grandmother. Voila. Another unknown person at the top of the next chain. The report is now down to 165 persons. Now, I will remove the 2 fake intervening records, and reconnect the other primary great-grandfather and great-grandmother. OK. It's now back to the same 216 person report I had above with the 2 new unknown persons, because they were recently entered records. Repeatable. Could it be that the size of this database encounters some Foxpro limitation, not evident with smaller files?

I looked at the change list for the Sept 2007 SP for Fox 9, and Unicode still wasn't in there. It probably won't be, ever, since there's no FoxPro 10 coming. TMG7 has no change in this regard, since the underlying FoxPro is the same. (WHERE DID THE EXTRA SPEED COME FROM??) If and When MS forces a change to another database (SqlServer???), try again.

They are where they are in V7 because that's where Microsoft wanted it for current (if you have Vista) or later (if everyone else has Vista). The files are more scattered in V7 than they were in V6. It should be in the paths with your computer username in there. The only dataset I changed myself was the backup, because I wanted it on another hard drive. Once you have played with V7, you will not want to go back to V6. Nearly everything runs a bit faster.

That is one indication that this PARTICULAR conversion did not complete correctly. I've seen it. How many persons do you have in your V6 database? Go back to V6 and make sure that you first have done an optimize, a validation, and another optimize before backing it up. The additional optimize is needed, and shrinks the file back down and restores the speed. That is also a rule of thumb on TMG7 for normal use. There is another trick that others have encountered when making the V6 backup. Normally it doesn't make any difference. I successfully converted several small projects without any extra intervention. One is to backup V6 WITHOUT any compression. That minimizes dynazip errors in the .SQZ when doing the conversion. Don't try to back it up and do the conversion on a flash drive either. There isn't enough room for the temporary files needed. Keep it on a hard drive with sufficient free space. Failing this after trying again, send a message to support *at* whollygenes.com with the problem description. If the dataset is extremely large, there are some measures that they can take with it, and return it to you. Once you reach TMG7, you will find it a lot faster than TMG6. That's an extra bonus.

I have some data IMPORTED from GEDCOMs and there are some witnesses. I swear I've seen 'em, but I didn't put them there.

Same here...I needed the screen width. I wonder why those buttons couldn't have been in the top bar instead.

I am continually amazed by the speed improvement in TMG7. Even without any other enhancements, it is worth the upgrade. I was afraid that with my current data file amd multiple projects I would soon have to keep two computers busy with two copies of TMG6 processing different things simultaneously. Fortunately, that isn't necessary with TMG7. Earlier this evening, I had 15 minutes to set up a compressed pedigree report to run before I went out for the evening. It had previously taken nearly an hour in TMG6. The silly thing kept finishing. I was able to run it 3 times in that 15 minutes, modifying the options a little each time to see changes in the output.

http://www.webdesignfromscratch.com/web-2....style-guide.cfm This is a "web 2.0 style design" page, I guess. It's a very loooooooong page with looooots of graphic elements, which right there is a turnoff for dial-up users. Somewhere along the line, KISS/Keep It Simple, Stupid got lost. KISS methodology does put more demands on the page navigation system, if there is one. After that, I noticed that they mentioned a lot of things that they did NOT like, and an admonition to "buy the book". Well, maybe not, from what I've seen so far over there.

I've seen some "new" interfaces in new products, with lots of flash, music, fancy interfaces that are unintelligible, and crashed and blue screens of death to boot. Well, yes, I did have to boot the computer a lot after that. Do you want to see some? Many are here in this bad design page, that laughably has been around for several years. They love beating up on commercial pages, most made by "consultants in whoop-de-do web design": http://webpagesthatsuck.com/ Don't mess with what works admirably, please. I'll pass.

I do like the focus group -- for ancestors and descendants. One other wrinkle -- TMG7 has enhanced its auto relationship calculation from what was done in TMG6. It does slow things down a bit, but you can ask for a full file refresh in preferences, check results and set your flags to match, and then turn it off again in preferences for maximum speed.

In the normal course of updating on V7, I have seen double primary tags, especially for things like marriages or birth dates. I am guessing that it could have happened after a member data merge. It hasn't seem to cause any problems so far since I was merging duplicates and the double primary was set to the same desired date. I haven't seen any set to DIFFERENT dates so far, as could happen with different source members set to different primary dates.