Pedigree-Compressed & ahnentafel reports incomplete

[retsof 0]

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.

Edited February 13, 2008 by retsof

[Mike Talbot 0]

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.

 

Compressed pedigree works fine for me on both starting subjects converted from 6.12 and starting with new people entered in 7.0.

 

All my tests were output to MSWord 2000 files. My dataset has about 80,000 people, if that is meaningful for you. Tests run on 3.4 GHz Pentium 4, half-GigaByte memory, Windows XP Home. I have kept 6.12, but only use it for verifiction purposes, when something on 7.0 looks strange. I have found no conversion problems, so far.

 

In 6.12, I had a lot of trouble with compressed pedigree reports output to Adobe PDF files. I don't do that, anymore.

 

Let me know of your options, if you would like for me to run more tests.

 

Good luck,

Mike Talbot

[retsof 0]

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?

Edited February 13, 2008 by retsof

[Virginia Blakelock 0]

You have doublechecked to verify that BOTH 'No Threshold" and 'Include blank surety' are ticked in the report options?

 

Virginia

[retsof 0]

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.

[Mike Talbot 0]

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. 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 exists 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 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.

 

Reran the test with output to the "print preview". The result on screen was perfect and agreed with the MSWord version on disc file (except the screen preview was prettier).

 

The focus person was newly entered into TMG 7.0 as were about 10 % of the ancestors. Several of "the converted from 6.12" ancestors had been edited in 7.0.

 

The only difference, I can see, is that I had no errors on the restoration (conversion) of the 6.12 backup to 7.0. My copy of the 7.0 program was downloaded from the TMG website about a week after the anouncement.

 

I'm out of ideas. Good luck,

Mike Talbot

[GenerationGoneBy 0]

Retsof,

 

I haven't followed this too well, but I just did a compressed pedigree to Print Preview for a person I added just this week. In fact she, her parents, and grandparents were all added in 7.0. The chart printed fine all the way back to her 11th great grandfather.

 

My next question would be have you OPTIMIZED, VFI, REINDEXED? If those don't work, I would contact tech support. Could be something wrong with that one project.

[retsof 0]

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?

Edited February 13, 2008 by retsof

[GenerationGoneBy 0]

The next thing I would double check is the report options. They could have somehow reset themselves. Make sure the sureties levels are set correctly. If so, I would contact tech support. They could have more suggestions.

[retsof 0]

none of this has changed.

No threshhold. Include blank surety.

 

If so, I would contact tech support. They could have more suggestions.

I told them to follow this thread. Edited February 13, 2008 by retsof

[Ernie Lee 0]

 

 

 

Edited April 6, 2008 by Ernie Lee

[retsof 0]

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.