elevator

I use two tags; emigration and immigration, one being the place you left and the other being the place you go to. I have many cases where a family member left Norway to immigrate to the United States. The sources show that person had to declare his intent to EMIGRATE from Norway with the Norwegian authorities, the get on the ship and once in the United States he had to declare his intent to IMMIGRATE to the United States. In most cases this was two different dates and two different events and it was therefore logical for me to use two tags. This way it is also easy to record information related to the process of leaving Norway and record information related to arriving in the United States. Ken.

Your post didn't indicate whether or not you click an already existing citation from the list of citations for a particular event or if you press the little button with the "+" (plus) sign on it. The plus sign button will add a new citation at the bottom of the list (use the arrows to reorganize) and the minus button will remove the selected citation. Forgive me if I misunderstood your problem. Ken.

Terry's system is great but it is still not usable for sharing your work with other genealogists. Say a friend calls me and says he wants to see the exact line from Person A to Person B (and those two are not blood related as often is the case), there is no way Terry's system can provide me with an e-mail'eable report. Furthermore, Terry's system can't be customized on a per case basis. I must fedine flags and preconfigure the lines I need to know in advance. I can't dynamically check the line between two random people in the database. Imagine the theoretical number of lines my database would have where any number of my 4000 people could connect in any manner. If you have tried the "Relationship Chart" you will see what I mean. That aside: Terry's page is a must see for all TMG users. Ken.

I use this exact system to indicate my interest in particular lines (what is sometimes called Ancestor and Descendant Interest) and for that particular use it works like a charm. I am not sure what the original poster had in mind; but for me I'd like a report like this that can be mailed to someone to shown the relationship path, for example: Me->My Father->My grandmother->my great grandfather's second wife->her brother->his daughter->her son. Clearly not a blood relationship but very useful to show how a particular person ties into the intricates of the family tree. I was thinking something like the "Relationship Chart", but with extended capabilities. Again, I may have misunderstood the request of the original poster. Ken.

I agree, I've been looking for a way to display the COMPLETE genealogical path between two people regardless of blood relationship or not (provided of course they are physically connected in the family tree). It seems to me like this is impossible to do with the current report definitions. If I try reports, I always get a message saying: No blood relationship found between Subject A and Subject B. I join Phillip in his wish to incorporate such a feature (if it doesn't already exist). Ken.

Det er da mye prat her... mest på engelsk da! med vennlig hilsen, Ken.

Hello and Merry Christmas to all! Now in these holiday times it is time for baking and cooking and carrying on all those precious family recipes for your favorite cookies, dishes or desserts that grandma used to make for every special occasions. I have a large number of these rather old hand-written recipe books and wondered if anyone had any ideas how to register this in TMG. Now, I realize that this information strictly speaking has nothing to do with genealogy, but in my case, for example, both my grandmothers were/are fabulous cooks and that fact very much defined who they were/are and so I'd like to preserve this information. Plus in the event that these books are lost, the recipes are recorded electronically. In the (distant) past I used a long since deprecated program called Sierra Generations that had an addin called "Master Cooks" that allowed you to register presicely this information as part of the genealogical information. How would I go about recording the contents of such a recipe book? Any ideas? Thanks, Ken.

Yes, I have the same problem, but I disabled the automatic updates only because updates are very infrequent, and since I frequent this board almost on a daily basis, the feature isn't really vital to me anyway. Ken.

I hope this was meant as a temporary solution until the real problem is found? It seems to me that the solution is not to disable the automatic update, but rather fix the problem so that if the program is updated, it silently does nothing instead of displaying that confusing message to the user. Guiding the user to a newsletter, when the automatic update is a program option defeats the whole purpose of an automatic update option in my mind! Ken.

This was brought up once before I remember. I completely agree with you. I have a rather complex folder structure with /exhibits/<personID>/ and /exhibits/sources/<sourceid>. It works like a charm and I am really happy with the way everything is organized... however... if you happen to move the database to a different logical or physical drive or change the relative path holding the exhibits folder structure, ALL links are broken. There are programs out there that fix it. I used Visual FoxPro that use to come with Visual Studio 6.0 a while back. It works great for changing broken path links. I do afree with Daniel James Gullo though, storing the relative paths in the exhibit table would make more sense than storing the absolute paths. The way other programs work is that they allow you to set a "base path" to lets say: C:\TMG\Exhibits\. If a user then chooses an exhibit located at C:\TMG\Exhibits\Sources\SRC00456\census.tif, the only the relative path \sources\SRC00456\census.tif would be stored in the exhibits table. The program would then construct the absolute path by concatenating the base path and the relative path. I think the exhibits system works ok like it is, but this would certainly add a lot of ease to people who use more than one computer to work on the same data. Ken V. Nordberg.

I use the Picklist of people a lot when I go through church records on microfilm (i.e. i use it to filter out everyone born within a certain date range in a certain place). However, when you close down the program and restart it, then open the Picklist of People again you get the following message: "Would you like to restore the filter which was active when this project was last used (C:\Nordberg\Database\CONFIRMATIONS DATE RANGE.flp)?". If I click Yes on this dialog the filtering engine goes through the filtering process and says that it found 20 people like it should, but when the Piclist is displayed it still shows everyone like no filter was applied. Is this right? As it is now, I have to go back in, re-load the filter definition from disk and reapply it everytime I open the program to continue research where I left off. Not a big deal, just wondering if this is a known bug or if I am doing something wrong. Thanks for an awesome program, Ken. By the way: I am using TMG v. 6.12.

Thanks for your supply Vera. I am glad to hear it's not just an issue with my installation. To answer your observations: Yes, if I open the picklist in the same session everything is fine. If I have changed something, the filter is re-applied to show newly added data, but that is of course just what we would want. The problem is when closing the program completely and going back in at a later time to resume work. My layout does not have the Project Explorer in it, but I tried it with what you said and I am experiencing the same problem you mentioned. I appreciate you reporting the problem. Not a major thing, but a little annoying nontheless when you need the feature Take care, Ken.

While I haven't exported anything since the 6.11 upgrade, I have kept really close eyes on the count (for web publishing purposes) and it has always updated and been exactly accurate for me. It would sure be nice to figure out what's causing it in your case though and establish that it is not a bug (hopefully) in the latest update. Ken.

Good evening, I took this up in a previous topic but would like to add it to some sort of wishlist (not sure if this is where to di it?). In any event, for people who have died but no sources exist to document a death date or death place I normally set the standard living flag to N to indicate that the person died. However, when exporting to GEDCOM to data is left out, leaving no traces in the GEDCOM that the person died. The ideal way (for me anyways) would be to export a 1 DEAT Y gedcom tag to indicate that a person is in fact dead but no other data surrounding the death are known. When I realized TMG didn't do this I even went as far as to create an uncited Death tag, but even that simply exports as 1 DEAT (which makes no sense to external programs utilizing the GEDCOM standard). I hope a method can be implemented either by using the Living flag (ideal) or through an empty death tag that would allow the information to be exported to GEDCOM. Thank you very much, Ken.

I can live with that. It sounds quite logical. The main thing for me is the final effect of the information being exported to GEDCOM, if that is done through a flag or empty death tag really is secondary to me. I was just illuminating cases where I for example have an ascendant that lived in the 1500's. Obviously this person is long dead. It seems to me in this case to be wrong to input a Death tag in TMG because it would then be citationless which in turn indicates poor citation procedures. In this situation using the flag would make more sense because the person is LOGICALLY presumed dead (because no one lives to be 500 years), whereas using the death tag assumes that he is DOCUMENTED to be dead. Using the flag I think illustrates this difference. But like I said, your proposed solutions fits me just fine and I don't mind inputing a death tag and citing myself as the source with the note that since person lived around 1500, he must logically be dead. Thanks for your help Jim. Ken.

Good evening, I have a problem with exporting GEDCOMs and the DEAT tag. I use GEDCOM to export data from TMG to my phpGedView website. I have a large number of individuals in my family tree going back to around 1500. I have no documented data on these people except their name, which means they have no death tag. However, I do set the Living flag to No because obviously these people are long dead. However when you export the GEDCOM from TMG there is no DEAT tag. If there is a date, it correctly exports: 1 DEAT 2 DATE 08 JAN 1590 but if there is no death date the DEAT tag is completely missing despite the fact that the Living flag is set to No. Shouldn't the DEAT tag still be exported showing the line: 1 DEAT Y to indicate that the person is in fact dead, just no date is known. I have seen other programs do this correctly, is there a reason why TMG does not? Or maybe I have just missed an option telling the export functions to export DEAT tags based on the Living flag? Thank you for any help, Ken.

Hi again Vera, No worries, a little fun is never taken personally. No I am not saying that TMG is doing anything wrong, because the Y identifier of the DEAT tag is clearly not REQUIRED, but from the standpoint of the standard it seems that it was intended specifically for situations where no DATE or PLAC tag is present, so why not take advantage of it? phpGedView for example uses this tag specifically to calculate privacy for living people in the family tree. I disagree. If you look at an exported GEDCOM from TMG it exports other "default" flags like the Ascendant and Descendant interest flags. Clearly these are far less valuable than the living flag. It seems to me like a vital part of a person's file is left out when exporting GEDCOM's. What can be more important to export if not wether or not a person is actually alive or not? In the same way if the LIVING flag is set to Y, clearly there is no reason to export a DEAT tag because the person is still alive! Making it a wishlist topic may be a good idea, I just wanted to vent the idea to see if anyone has discussed the issue before. Ken. Just a short little anecdote. I have one person in my database born in 1935. I have no sources to document his date date or place, but I know he recently died so I set the Living flag to No. When exporting this to GEDCOM, as far as GEDCOM is concerned this person is still alive Ken.

Hi Vera, Thank you for your reply. Standard GEDCOM specifications indicate that if a person is documented to be dead but no death date exists, you can still use the DEAT GEDCOM tag to indicate that a person died but that no date is given. It seems logical to me because TMG exports the Sex flag, why not the Living flag? They are both default flags. My problem is that there must be a way for an exported GEDCOM to indicate that a person has died, regardless of whether or not a death date actually is documented. Exporting a birth tag if there is no birth date is absurd because if a person is in fact entered into your database I would assume that person was born (unless we're entering fictional characters) Here's the GEDCOM 5 definition of the DEAT tag. n DEAT [Y|<NULL>] {1:1} The specifications says that if no death date is known two formats are allowed: 1 DEAT Y or 1 DEAT 2 DATE UNKNOWN Even though superfluous, the same is allowed for the birth tag. It then makes perfect sense that TMG should allow the implementation of this, especially since a standard flag exists (LIVING) that controls just this. I could enter a blank death tag, but it seems like a bad procedure, because according to good research practice, all tags should have sources, and if I have no sources for the tag in question it makes perfect sense to use the GEDCOM standard mentioned above since: 1. it does exists, and 2. TMG has a flag controlling it. The LIVING flag in TMG even allows you to set it to ?, so if you do not know if the person is alive or not, leave it at that and no DEAT tag would be exported to GEDCOM. All bases are covered that way. Ken.

I agree with you. Maybe the Marriage tag should be renamed "Married", indicating a particular point in time when the marriage was established (i.e. through a wedding ceremony, or trip to the courthouse, or whatever). However, the other dates that are interesting in the context of a relationship between two people is really only engagement and divorce. The latter two have their own tags anyway. The only reasonable explanation to me is then that the start of a relationship is signified by an engagement or a marriage tag and the end of a relationship is signified by a divorced date or a death/probate tag for one of the partners involved. Ken.

The way I have understood it, it should always be the date that the even took place. Potentially, all tags can have a date associated with them including tags you would normally not think about dates such as SSN and occupation. However, me for example being an immigrant to the United States didn't get my US SSN inssued until a certain date. In my case the data field would reflect such an issue date. Similarily people may have had many occupations throughout their lifetime and the data field can then be used to specify a date range when the occupation was held. All fields on the tag entry screen should in reality deal with that particular tag. If any of the fields are not applicable to a particular tag, they should; in my opinion, be left blank. Ken V. Nordberg

I always make sources for those kinds of exhibits (birth/death/marriage/baptismal certs, passports, deeds, etc). Only photographs or exhibits that naturally are connected to one (or maybe two) tags I attach to the tag. Yes, there will be quite a few sources after a while, but I have found the master source list to be easy to navigate and plus I feel like the citations for the tags are much more organized. I also always know where to find an exhibit and there will be no exhibit redundancies. For me your option 2a works the best. Good luck, Ken.

I apologize. Having used your website to learn so many other things about TMG I just assumed your site was where I had seen the article about the photograph tag. I guess I must have seen it someplace else. Nevertheless, your site is a must see for anyone new (or not-so-new) to TMG. Ken.

I have done the same thing. I make the tag for the "principal" person (or couple) in the photo and the attach everyone else as Witnesses (with a custom photographed role) to the tag. I believe Terry Riegel has a detailed explanation on his wonderful site on how to do just that. Ken.

Just reporting that I have had the same problem. The same problem also seems to manifest itself while adding new accents or clicking the "apply" button. Ken.

I personally just attach the documents you mention to the corresponding sources. For example the digital scan of the birth certificate of whomever get's attached to the particular source for that document. It works great I think. I have an intricate folder system where every source and every person has his or hers own folder where all the documents are stored. That way they are easy to find. A separate document manager feature, would in my opinion make the whole system harder to use. Maybe if we could replace the current system with a more robust and feature rich system; that would be something to consider? But having the possibility of storing digital documents both in a document manager and in a source/pesonal file seems a little redundant to me. Maybe I misunderstood your question? I'd definitely like to see an improvement in many areas of the current exhibit management system though :-) Ken.