retsof

Have you changed the compression parameters from normal to none or most to get anything different? It may not matter much unless your database is large, as this one is. A validation itself runs about 6-7 hours on one core of an AMD 3.2GHz Athlon X2 computer. Optimize is 20-30 minutes each. I am merging many duplicate records from some assorted GEDCOM imports, but it is very time consuming. It seems counterintuitive to not run a backup before a long maintenance run, but it seems that is what I must do. Backups only work on clean databases. That does seem to make sense, since Dynazip seems delicate. Optimize/Validation/Optimize is in progress from a recent restore of the recently optimized database. Validation fixed a few errors and is clean. It seems to be running better today. Yes, the validation kicks up the size of the database, and optimization pulls it down again to where it was the first time. If the validation has a problem, I had also not thought of running an optimize before running another validation. I found a new problem that seems to interfere. The notification screen for the automatic Microsoft update usually seems to be around when Foxpro stops working. (Vista Ultimate) I changed the setting to let me decide when to download something from Microsoft. Perhaps I get get through a good run again.

I was trying to back up the database BEFORE optimizing and validating, but it could need to be optimized for a restore to work, since it didn't restore again after a bad validation (compression=none, but still had bad dynazip problems preventing loading of several files). I lost another day of updating since the data was nonrecoverable. I am trying to merge some duplicates and near duplicates to cut down the size of the database. A restore from a previously optimized version restored correctly.

This falls under the "why". Why is 90% of the time spent in my file validation process (hours) consumed on checking witnesses, even though there aren't any to speak of (< 10)? It's checking for principals that are not witnesses at the moment.

I had some set numbers, but have found a couple of times that the system had a mind of its own and changed radio buttons to renumber the whole dataset, even though I only wanted to renumber one person. What happened? This is a large database of over 484,000 entries, and I am still combining duplicates. There were a lot of gaps. When the database was freshly renumbered, IT THEN HAD FASTER ACCESS. Perhaps some of the internal database ID key tables were smaller if there weren't a lot of gaps, and the disk didn't have to bang around searching for numbers farther removed in the database and widely scattered. The database had previously been freshly optimized, and this was a speed improvement beyond anything optimization could provide. If you don't want the numbers to move, all gaps with smaller number have to be plugged with some data.

We wouldn't want to leave those Vista Basic users out in the cold.

We do not yet know the direction Microsoft will force to replace Foxpro, when or if it gets replaced. So far, Foxpro 9 is slated to be the last one. When and if that happens, we all hope that Unicode would be a part.

I have a situation in Ritchie Co WV that I still haven't figured out. There may not be an answer. The same named child has two birth records on adjacent lines of the birth ledger. Both records have the same father. The first line lists the first wife as the mother and the second line lists the second wife as the mother. The birthdate is about a month after the marriage of the second wife, but I found no local death record for the first wife. With the internet and the SSDI now, perhaps it's time for another look. One or the other will probably end up as the primary mother, probably the second wife, but it's uncertain.

Gay/lesbian is only one concern. At least descendants would be adopted. I don't have any polygamous or polandric or communal situations either, but suppose that it would be possible for some situations with more than one wife/husband. I was wondering how to number the individuals uniquely (reference number), should the situation ever come up.

Flash drives should be used for TRANSFERRING data between computers, transporting it off site or holding it as a disaster backup. It is not recommended for live crunching because of the high disk activity. Optimizing or validating a TMG database on a flash drive sounds too intensive for me. It could degrade after something in excess of 100,000 write cycles to the same flash memory location. Trying to restore from a flash drive directly can also cause a problem because the decompression of the file needs some space which can quickly overflow. Storing TMG backups on it is certainly a valid use, but transfer the backup to the hard drive before trying to restore it. 2 Mb sounds more like main memory, and could actually be 2 Gb. The flash drive actually acts like a large floppy disk drive, without the floppy. It is more comparable to the hard drive since it contains data files. Entering something on it on a text file from a word processor at a remote location is not as intensive and wouldn't hurt it. If your HARD DRIVE is running out of space, there would be other issues (access, speed, frangmentation, temporary internet files filling it up) that the small (even 8 Gb) flash drive could not fix. This desktop has two 500 Gb hard drives or one Tb of hard drive space. Even laptops these days usually have 50 Gb to 200 Gb hard drives (roughly estimated).

TMG 7 uses Foxpro9. TMG6 had an older version. Even with service packs, there is no Unicode support in Foxpro. Yes, it is a Microsoft problem, because they have already said that there will be no Foxpro10. The subject comes up now and then, because of foreign font accents that some would like to use. Microsoft is a challenge, but Foxpro9 is definitely the starting point on their site.

On the report definition screen there is an options button in the lower left. Go there. There is a place to change the number of generations ... up to 250. Some of the reports can run a long time if you are uncertain about the results. I'll set the number to 10 or 20 to check the output and layout, and then go for a large number.

For a fairly large database, some records will not generate a pedigree compressed report when set as subject / one person(s). What records? They seem to be new records added in TMG7. Father of the suspect record was originally entered in V6.12 and converted to V7. A report with that person set as the subject works just fine. Other records converted from V6.12 work correctly. Other records added in V7 do not. A regular pedigree report works correctly in both cases with the same original V7 record that does not work for the pedigree compressed report, so it's not an all-encompassing thing. Virginia Blakelock asked about settings in the message group, and they seem to be the same for both cases. I am not using V6.12 any more. The skeleton is just sitting there. V7 has so many other improvements, but I am benefiting most from the overall speed. The database has been optimized/validated/optimized again/backed up/restored without change in symptoms.

It's a real error. Tech support had it for a week and handed it off to the programmers. There's some kind of internal numeric overflow in data ENTERED IN V7. The data previously entered in V6 reports just fine in an ahnentafel or compressed pedigree. A regular pedigree report with the boxes shows all records. If the data I entered in V7 is copied to a new dataset, THE ERRORS REMAIN. They are still scratching their heads about it. There is a 2 gigabyte maximum size of Foxpro datasets. I don't think that I have hit that, and haven't seen any alarms. I can see all of the data I enter. I've just stopped for awhile and will work on other projects until more is known about this report problem. This is a very large datafile. This type of error has not showed up in small or medium projects. Actually, I may be the first.

If worse comes to worse, make an UNCOMPRESSED backup on V6, and restore the V7 from there. Since nothing is compressed, dynazip will not be involved at all. You DO have to have enough space for a backup that is 10 times larger than a normal compressed backup.

places with no events... Any tag can have a place...Christening, occupation, etc. etc. I'll still put the non-place information into the memo field. I end up MOVING a lot of place information into memo fields, since a lot of GEDCOM imports put it into the place. I notice that every comma becomes a separator that puts part of the import into a different place field.

I had been using Doe(Smith) as an extra, but I like your idea of (Doe)Smith to gather all of the maiden names under the "(" index in Second Site. I only use one of these to cover multiple marriages, as (Doe)Smith-Johnson-Brown I originally thought of using Jane Doe Smith Johnson Brown (Doe)Smith (Doe)Smith-Johnson (Doe)Johnson (Doe)Brown (Doe)Smith-Johnson-Brown to cover her complete timeline, but that was overkill. I am sticking with Jane Doe as complete maiden name Smith generated for first marriage Johnson generated for second marriage Brown generated for third marriage (Doe)Smith-Johnson-Brown manually added TMG will fill in the complete name in the picklist, so there will be another entry for every name-marr Exception: If somebody marries a cousin or somebody with the same last name, you would have Jane Doe Doe generated for first marriage (Doe)Doe manually added The picklist would show two entries for Jane Doe. I remove the first name-marr. It's too much thought to remember NOT to generate it in the first place.

I also remember posting over there. I don't think that the LENGTH of any name will cause a problem.

If maiden names are entered from the bottom up, when parents are entered, it can be set to prompt and enter the married name (NAME-MARR) automatically. I enter ANOTHER special married name (only by personal preference) containing the maiden name and all married names in parenthesis in order, if possible. Why? I'm a Foster. My grandmother was a Smith. Another grandmother was a Johnson. Several other prolific families are in there that are tightly intermarried, so I need some specific combinations of names. I needed another way to quickly find some of these people with common surnames rather than looking at several pages of Smiths.

I prefer to use ID = reference for the first hundred or so direct ancestor ahnentafel numbers to reduce confusion, since those are heavily used reference points. I will renumber single individuals to get to that point if I can. Naturally, ahnentafels double with each generation, so that only goes so far. I only go as far as the highest existing ID number for that scheme. By that point, it doesn't matter that much. My reference number is an ahnentafel-Sosa-Stradenitz system, so everyone connected in any way by ancestry, marriage, descendancy, or ancestors and descendants of spouses can have a unique reference number, leaving room for logical additions of more.

It doesn't appear to be multithreaded on this X2. I got the fastest core AMD I could get to speed it up as much as I could, a 3.2GHz AMD X2 6400+ black edition overclocked at 7.8% and with a large Zalman fan. The AMD phenom quad cores are still too slow. The current Intel Core2 Duos are faster for something right now. Version 7 also runs faster than Version 6, which is another help. My background grid computing DOES use both cores, so at least one of those will always be running during a database optimize or VFI, which takes 100% of one core.

I haven't found any obvious limitations to using the suffix, since it shows up on the picklist and in windows, as opposed to making a new style in various places for pre-surname. (Why wasn't pre-surname in the standard style and windows to begin with, I wonder?) It is a natural place for things like de, di, ap, verch, von, van. I have some French names like Jean Célérier dit DesLauriers and I'll put dit DesLauriers in the suffix It translates as "known as DesLauriers". I also use the suffix as a spot for royal generic designations not strictly part of the name, like "the fat", "the unready", "the boneless", etc.

I have some names like that in my own data. I use both Rodriguez and De Rodriguez, with one entered capitalized as a surname in the alternate name variation (Ctl-V) so I can find them if uncertain. I am never sure whether the de/De is part of the surname or not. (comment?) For the first example, I use uncapitalized "de" either following the given name or in the presurname field to show that it is not part of the surname for that version. Maria Irizarry Y Feliciano de Rodriguez Maria Irizarry Y Feliciano De Rodriguez I will then have surnames Rodriguez De Rodriguez I need to change some styles to get the presurname to show up in all places and windows. Anything in the surname field will be indexed as-is for the picklist sorted by surname.

Everything is fine, but there could be a previous copy of TMG that is running, or it stayed there after exit. The icon may not be visible, which is why the new attempt says that it is in use but you don't see it. Exit the one you see for a clean ending, with backup if needed. It is easy to detect the other one by running the task manager (ctl-alt-delete). (tmg7.exe for the current version.) The task may be ended there. End the task manager and restart TMG as usual.

A new V7 project should be RESTORED from a V4 .SQZ backup, I would think, not imported. I use import for bringing gedcoms into an existing V7 project as a separate dataset. The new dataset can then be merged with the existing dataset in the dataset manager. That is a different animal.

Why thus? Work should not be lost by restoring a new V7 project from a V6.12 .SQZ backup.