Jim Byram

Arman,

Using WinXP... I'm wondering if the issues are being encountered because the installation in Program Files is an 'all users' installation rather than an installation for the specific user.

I experimented with my 'single user' installation in Program Files running my user with non-admin rights and manipulated various files in the program folder with absolutely no problem. (tried app.ini, repeat files, webother.txt, the Sample project, etc.)

On the other hand, with an 'all users' installation in Program files, it was completely unusable by a single user since none of the non-static configuration and data files could be changed by the non-admin single user.

If WinVista locks down program Files for even single user installations, then there will need to be changes. This is a non-trivial issue since many of the non-static files in the program folder are used by all users. In addition, static files can be added by the user to the program subfolders such as frames and graphics.

Jim

(This is not an official Wholly Genes response.)

I am trying to import a PAF file into TMG but get the following error "Declare DLL caused an exception 114PAF4MAIN". Does anyone know what this means?

Yes. I'm guessing that you aren importing from the File menu (File / Import) and there is a known bug when doing this.

Do the import from the Welcome screen (Welcome / Import) when you start TMG and this error shouldn't happen.

Sorry. This has been on my to-do list for a long time and I've just gotten to it. v6.07.000 appears to be running just fine under WinXP Pro x64. I still need to exercise all the cracks and crevices but see no problems at this time.

At this point in time, I wouldn't recommend anyone running x64 as their default operating system unless drivers exist for all of your hardware and all of the applications that you typically use have no issues. There are also some limits to web browsing that require working around with the 32-bit browser. Put another way, x64 is not for the casual user.

Kevin,

My inclination is to do nothing. I built a test GEDCOM and tried it with GenViewer and Family Historian (which uses GEDCOM 5.5 as it's native database).

GenViewer uses the last source memo found which means it doesn't accept duplicate source NOTE tags just like TMG. Family Historian accepts both source notes but has no structural constraint since it is using the GEDCOM file.

Both programs reject the REPO structure since it is completely illegal. Repository records are top level records in a GEDCOM. It is illegal for the repository to be buried in the source record. Note that TMG actually imports this but is having some difficulty with the structure.

This represents just one of many instances over the years where FTM ignores the GEDCOM specs and does it its own way. The trick is to import this to something like PAF to see if the data gets in and create another GEDCOM from there.

This particular file is not a big undertaking to clean up after import since we're not talking about much data to hand correct.

(from what I can see, the GEDCOM 5.5 standard allows multiple NOTE structures at the +1 level)

The specs are not clear on this point. The practice from what I can see is to have one NOTE tag per source. It's hard to see how any program could have more than one NOTE tag since the program note field for sources is typically one field.

- NOTEs at the +1 level to the REPOsitory do not show up in the Source Supplemental or Repository Memo fields but sometimes show in the "Not Processed List".

As notes above, the REPO structure in this GEDCOM is illegal. And I would again think the practice to to have one repository note for the same structural reason as with sources.

- The Call Number (CALN) tag is put into the reference field of the Repository Link Entry Screen. The entry is truncated to the 25 characters of this field even though the GEDCOM 5.5 standard allows 120.

I don't see this tag as being different from any other GEDCOM tag and can have unlimited length by way of CONC and CONT statements on the following lines. In any event, the length of the TMG field is the length. The design of TMG is not driven by what GEDCOM does or doesn't do except for following the rules on export.

Does the MEDIa tag in the source map to a particular location?

Don't think so. the TMG option on the Supplemental tab is a list box of set choices and it would be hard to map the GEDCOM tag to that design.

Jim

If you ran VFI with the two correct paths in the search, each image path should have been corrected. This didn't work? I have tested this extensively and have never seen it not work correctly. The message at the end of the VFI run has nothing to do with the exhibit search.

It helps to disable thumbnails when checking exhibit paths since thumbnails hide what is going on.

In any event, the external exhibits option of VFI should take care of your changed paths if each exhibit has a unique name and you entered the two paths where the exhibits currently reside.

However, that leads to the next question/issue. Many of the sources in the GEDCOM have a NOTE tag. For some, that information shows up in the comments box of the Supplemental tab where I expected to see it. For others, the actual note shows up as an unprocessed line in the Import .LST file and for others the note seems to be just "missing".  It is not in the source supplemental and not in the unprocessed list. How should these notes be processed during the import?

If the NOTE tag is subordinate to the source record tag (in other words, 1 NOTE), the text should always be imported to the note field on the Supplemental tab. You'll need to point me to some examples to check.

Hummm... There are 40 NOTE tags in the sources and all are using xrefs so don't yet see a reason why some would work and others not.

There is a 30th. CDX file called back_I.CDX, it has a much earlier date than the others, several months, it seems to contain exhibit captions, there is also a coresponding back_I.DBF file to go with it. Is this a stray and can I get rid of it?

Ray,

You used PathWiz! with your project? I think those are the PathWiz! backups. You can delete these files.

Jim

The problem is that you selected:

Step 5: GEDCOM Options 1

Convert widowed SOURce tags

This option will never apply to any GEDCOM 5.5 file which is what you are trying to import. In fact, I've never seen a GEDCOM file that required this option other than the GEDCOM that I created to originally test this.

Stick to the defaults except where you understand exactly what the change does and that you need to make it. For example, it made sense to select 'Assume marriage of parents'.

You need to look at the GEDCOM and the differences with a given option to see if a change makes sense.

You will need to use Step 7 to assign the custom GEDCOM tags as custom tag types for import.

There is nothing intrinsically wrong with the first source that you say doesn't import so that points to the citations as the issue.

I need to see the GEDCOM. How big is it when compressed into a ZIP file?

You can contact me by email by clicking on the link below:

Jim Byram

I had a desire to use  Open Ofiice but I cannot see it mentioned as  a TMG option.  Can you inform me how you do it?  - Please.  I presently export to word.

For the file type selection, I would suggest using either 'Word for Windows 2000 or later' or 'Rich Text Format (RTF). Both worked fine with OO 2.0 last time that I tested.

I tried to restore a backup to my drive H - a removable "disk".  When I chose that drive a pop-up said "Wrong destination path."  I see nothing in the help system that tells me why that shouldn't work.  Why doesn't it?

I tried this with a flash drive and got the same result. Will report it.

Shouldn't be although the permanence of unlinked places is always an issue. I tested this and couldn't remove the unlinked place with Optimize until I deleted the exhibit.

Michael,

You made a critical omission when you set up your test.

When you set up source #1, you need to tick the ibid selection 'ON - Requires same source and [CD]' on the Output form tab.

There is a bug and a design omission.

The bug is combining source endnotes/footnotes (with combine selected) with exhibit output to endnotes. This causes a recursion issue where report output is prematurely terminated and an endnote/footnote contains citations to itself.

Issues like whether the exhibits endnote section should have a title when standing alone is a design issue, not a bug.

Jim

Tab characters in memo fields are consistently stripped out during the gedcom export process.  They are entirely missing in the gedcom.  This happens with an actual ascii character or the [:Tab:] code.

All formatting codes are stripped out by design since they are meaningless to another program. Don't know why an actual TAB character would be stripped. Have to look at that.

I have also found that if I select the "Break long values between words" option that the space between the two words where the break is made is stripped out.

Trailing spaces are stripped by design. If an importing program uses this CONC form, it should understand to add the space on import. You should use the default CONC form (which is the correct form breaking within words) if possible.

Doug,

With the next update, hopefully, you should find that the output is consistently FORM JPEG. If that's not the case, please let me know.

Jim

As I've reported before, I have trouble with a backup path that once in a while changes from "D:\TMG Backups\" to "Loadmode\".

This is clearly a PJC file issue.

It happened the other night, so I saved a copy of the .pjc file...

Could you send me that copy if you still have it.

TMG opened fine and ran with no problems that I could see. When I looked at the .pjc file again it seems that there is an "emrty" line added every time I start, or exit maybe, TMG. That is why I had so much white space. all those added lines.

Is this normal behaviour, or is something wrong here?

Clearly not.

Paranoid...... you bet.

Can't get too paranoid. Good practices save your bacon.

Click on the link below for my email.

Jim Byram

Kevin,

The problem appears to be limited to the E-table (witness table). The problem is that an EPER has records in the wrong data set (DSID). All of the individuals with problems appear to be in data set #2.

Your example Anna Maria Schmitz (2:3674) has two records in the E-table... one with DSID 1 and one with DSID 2.

Ewen Castor (2:1) has three records in the E-table, all DSID 1.

Persons 2:3696, 2:3702, 2:3707, 2:3713 each have one E-table record in DSID 1 and another in DSID 2. These four person records are grouped together. Maybe you can see some sort of pattern?

We're trying to make sure that all the records in the $-table (person) have the correct DSID. From looking at the records towards the end of the table, you've been entering new people into both data sets.

We've never seen the E-table issue. Have you been doing any particular sort of unusual data manipulations that might be tied to this?

If the issue is only an E-table issue, these records can be cross-checked against the $-table and corrected. An addition will be made to VFI to check for this sort of data issue and make corrections.

Update: The same DSID issue is occurring in the NPV-table and this explains the name loss with merge.

Update: Code has been written to repair this and I've tested it on your data. I can now repair your project and sent you an email requesting your current project to fix it.

Jim

I have used the default export config, Gedcom 5.5 with ansi.  I also did a maintenance - optimise and validate and it worked ok.

That suggests that a configuration setting that you made is the cause of the problem. Can you try to replicate what you did and determine which setting?

John,

Any issues with the RootsWeb mail list should be conveyed directly to Lee Hoffman.

Jim

The simple workaround is to create a custom Probate2 tag in the Other group and use that.

The simple answer is that each data set is in a different box by design and there are no data manipulations between data sets. This is unlikely to change.

The error is either the result of some export configuration selection or a data issue. Have you tried the default export configuration (which is GEDCOM 5.5 with the ANSI character set)?

Please detail any changes from the default export configuration so those can be tested.

The translations and language adjustments evolve with every version of the program. For that reason, you want to be running the latest version of the program. v6.07.000 is a very stable release. The only problem of note is an error when adding tags in Beginner Mode and you can click by the error or switch to Advanced Mode which doesn't have the error.

I would suggest taking advantage of the v6 registration that you already have and updating.

Kevin,

You should have been advised to revert to a backup with your initial report. And to hold off merging until the source of the issue could be pinned down.

You should also update your installation to v6.07 if you have not done so.

I've replicated the data set merge issue with your project and am looking at it. One of the programmers is also looking and the issue appears to be damage in your original project but it's taking a while to understand exactly what is happening.

Jim

I'm not seeing that. Click on General and I get Tag Type Definition: General. Click on Roles and Sentences and I get Tag Type Definition: Roles and Sentences. Click on Other and I get Tag Type Definition: Other.

It looks like the TMG.cnt file is the key to the links. Send me an email and I'll send you the file.

Click on the link below for my email.

Jim Byram