Mike Talbot

Sorry. The two that I know about are not Google searchable. You would have to put keywords or names on your webpage. They are mentioned in this thread and are: http://geneweb.inria.fr/roglo?lang=en and genealogics Best wishes, Mike talbot

Yes. You can see a fine genealogy website using that software at: http://www.genealogics.org/index.php Leo van de Pas' database of 400,000+ movie stars to kings and emperors to ordinary folks. A W.Ausrailian database of 200,000+ settlers to modern compile by another. The two databases are handled like a TMG project with 2 data sets. In addition to evaluating this sofyware, you might find some useful genealogy data. Best wishes, Mike Talbot

Did you try: File> Maintenance> Verify File Integrity ? If not fixed then try Optimize? I know it checks (and hopefully fixes) the index If that doesn't do it, I'm out of ideas. Mike Talbot

I don't understand half of your requirements, but for a compact screen format and user friendly website: See the roglo (INRIA) website at: http://geneweb.inria.fr/roglo?lang=en The database and features are driven online, including data updating, reports, etc.. Play with roglo's 1.4 million person database for a time, to get a feel for how you like it and reports. Best of all it's free to use, acquire and evaluate whether or not it has all the features you want. Click on the GenWeb link at the lower left of the opening page to download the software. The downside is that you will have to initialize the database via GEDCOM. The good news, you can run the software off-line to see if the GEDCOM exchange did a good enough job of translating your data. Most people on GeneaNet use this software. Good luck, Mike Talbot

Output the TMG FG report to MSWord. Insert(Word menu entry) the image file(s) wherever you like. You could altrnately drag and drop the image from Windows Explorer. Once the pic is in MSWord, you can move the image about, resize it, etc. Word lets you format the image in many ways such as place it behind text, etc. Experiment, it's fun. It's not as sexy as having TMG do it for you, but it works and the results are quite nice. Best wishes, Mike

Your way to split a database sounds great. But I think that you might be selling TMG Focus Groups and TMG GEDCOM Export/Import short, unless I misunderstood something. Recently, I’ve made GEDCOMs from Focus Groups for two 2nd cousins (one on my paternal grandfather’s side, the other on my paternal grandmother’s). Each included some siblings, collateral lines, descendants and with spouses and spouse parents). The resulting GEDCOMs were each in the 15,000 +/- headcount range. (My single project, single database contains 73,277 people and 7800 images to date and still growing. It is quite small compared to that of a friend, Leo van de Pas’ 500,000 persons single database (genealogics website) and the INRIA French group’s 1,340,000 persons single database (roglo website). As with TMG, I don’t see any organization or management problems with those really huge databases. What was a management problem was when I had 2 databases. The first of the two Focus Groups took a few hours to plan, but less than an hour to implement. The second went much quicker since the requirements were similar; the major changes were the base individuals. I’ve just spent about a day spot-checking those two new TMG databases imported from copies of the focus group generated TMG GEDCOMs. I had only spent about an hour spot-checking the GEDCOMs sent to my cousins (they use FTM), before seeing your warning message. The desired people, exhibits, sources (but only those items needed by the subset), etc., are all there, without a detected error. I guess that I luckily don’t use any TMG tags that aren’t covered by the GEDCOM specs. I use the “Note” tag often where another, more precise, tag might be used. I’ve found no compelling need for Custom Tags, yet. I’ve used TMG since 1997. Though one day, I do plan to revise certain sentences to remove all flowery TMG generated articles, pronouns, prepositions, verbs and the like from reports. I like to keep ancestry and descendant reports simple, professional and concise… including b., m., d., each date followed by location, notes, memos and respective reference. There is a major weakness that I see in using Focus Groups for the specific original case of splitting a database into three as in the original message in this topic. In my case, I have a few family fragments that are not related to me or in-laws in any known way. Examples: Joan of Arc, Gen. George S. Patton, Jr. and the like. I would have to add the base of those small groups from memory to a focus group (to use a custom flag, all flags could simply be initialized to a given destination database), if I wanted to keep them. Using the custom flags, there would be a TMG programmable way to verify if any unconnected people were not included in any subset. Using focus groups, the only verification possible is manual or a custom written computer program or becoming a Foxbase expert. The above major weakness of a focus group can also be an advantage over a custom flag. When making a subset of your database to give to a friend, a focus group leaves no otherwise useless tracks in your database. I do not recommend Focus Groups as the best way to solve any problem, but they do work. Custom flags do have some obvious advantages under some circumstances. Is the implementation of setting custom flags as complex as it sounds using LOP? It sounds as tricky as focus groups; the logic is just performed in a “different language”. To revisit the original question, I still can’t comprehend how fragmenting a database can result in better organization and management than keeping the original database intact. The ultimate manageability, using that logic, would be to keep each person in a separate database. (PS: It is my understanding that a TMG Database can be a member in only one TMG Project. So when I refer to a single database, I mean just that. Not a single project that may contain multiple databases. It seems that some might be using the terms database, file and project interchangeably when discussing TMG.) I do have other TMG projects and databases compiled by friends and relatives, but I only look at them and never modify them. If I find corrections or additions, there, I manually edit my own single database. My plea: never split a database for your own primary usage. Never delete or discard people from your database, unless the data is wrong and you can’t fix it. You will be glad that you kept some of them, one day. Please forgive my rambling on multiple issues. Best wishes and many thanks for your comments. I must try using custom flags one day, Mike Talbot

I like your way very much for those with one spouse. It would also be an ideal format for a VCF based Relationship Chart. One spouse per person is all that's needed there, except for the common ancestor at the top. The multi-spouse case with children still requires a lot more thought. Best wishes, Mike Talbot

Please clarify. Are you writing about the Descendant Box Chart, only? The descendant box format is now compatible with the Ancestor Box Chart box. I guess the Hourglass Box Chart would then be a hybrid of the appropriate two box format types? The TMG Relationship Chart uses the box format that you propose. However, it does not output to VCF, so the results are not pretty nor useful for other purposes. (Now there's a wish list item. Convert the Relationship Chart to use VCF, with images.) What should be the Descendant Box format for a person with multiple spouses with children from more than one of those spouses? Must one think outside of the box<g>? Best wishes, Mike Talbot

A variation of your question is frequently asked on this forum. Yes, there are many compelling reasons to make separate databases. One such reason is to give a cousin, friend or in-law a database containing only his ancestors/in-laws/descendants. You are obviously a serious, experienced genealogist to have researched over 40,000 people. One straightforward way to split databases: Make a TMG Focus Group for each desired database (careful, this is tricky to plan, but implementation is easy). Export a GEDCOM using each Focus Group, separately. Import each GEDCOM into a separate new TMG database. Voila! Recommendation: never, ever discard the original database, keep it handy. It is far better to have it and never need it than... Merging databases of even, no especially, distantly, multiply related people is much harder, error prone and requires lots of manual labor. Maintaining multiple databases that contain some of the same people is an almost impossible nightmare (management problems on steroids). Long and boring considerations before splitting your database: TMG’s job is to manage your database, no matter how big. It does that management very, very well. The TMG indexes, windows and tools make it easy to locate the person or data you want in even huge databases with a few mouse clicks and quick, simple visual inspection. Once the desired person’s record is found, access, additions and modifications are a snap. My database contains 73,000 people and I have had no problems managing it. TMG manages it for me. Once upon a time, I did have a database management problem. I had two databases. One contained over 30,000 and another of over 10,000. At first there weren’t many ties between the two. As time went on, the number of ties increased. Some people had to be in both databases for reports that I wanted. Sometimes I would update the data on such a person in one database, but forget or postpone updating that person in the other. Now that’s a severe management problem! Since I’ve switched to TMG (my old gen. program was limited to 32,767 people per database) and later merged the 2 databases into one, all my database management problems have gone. Among specific things to consider before spitting your database: Which database(s) will contain your daughters? Which database(s) will contain your grandchildren? How many databases will you need when you have great grandchildren? How will you make ancestry reports and charts for your grandchildren? Great grandchildren? Sure, TMG and VCF make those reports and charts possible, but a lot of time, ingenuity and manual efforts are required. Do you ever help friends and acquaintances with their genealogy, and then discover that they are related to someone or more than one in your database? What will be the size of your resulting three databases? TMG Focus Groups make it easy to determine this before you create any new database. Those focus groups will be useful if you still decide to split the database, despite the pitfalls. Can you be certain that your sons-in-law will not prove to be your, say, 7th cousins, one day? True anecdote: Here is an example of a married couple, with children, in my database. Their closest relationship is 7th cousins, once removed (thanks, TMG, I would still be counting on fingers and toes to define the kinship manually, even if I were lucky to discover it). Not such a close kinship as to raise eyebrows. In fact, only a serious genealogist could even discover such a distant kinship. As a couple, a TMG Focus Group shows that their children would have about 10,100 unique ancestors at the 32 generations level. A focus group on the husband, taken alone (the exact identical 32 generations), shows that he has 9100 unique ancestors. The wife taken alone has 6500 unique ancestors. Splitting them into two databases would simply result in more databases, each almost as large as the original. Consider a question: how many unique, recorded ancestors would their children have were their parents in different databases? Answer: There’s just no way to tell. The moral of the story, by splitting this couple into separate databases, I would not have significantly reduced the resulting database headcount in either database from the original, but I would have made ancestry reports for their descendants a nightmare to produce. If you keep to your single database, your descendants will be very grateful, one day. I believe that you would be thankful much sooner. Please accept my apologies for preaching. You've probably thought over these points in making your plans. Good luck and best wishes, whatever you decide, Mike Talbot (Been there, done that.)

I missed replying to this in my previous posts. TMG is better than that. In every case that I've hand-checked, TMG gives the closest relationship, not the first random one it finds. Best wishes, Mike Talbot

Thanks for your experience. I've let the Relationship Chart run for over 16 hours (3.4 MHz) with the default 250 generations and it never finishes. It has to be killed. The same RC usually works fine, if the max-generations parameter is set to 32 or less. You would see similar CPU usage percentage whether TMG is caught in a perpetual loop or is just taking a long time. As I previously mentioned, the Auto-Relationship Calculator update runs over-night, but the results are worth the wait. Are we talking about the same feature? Best wishes, Mike Talbot

I have some issues with TMG that seem to not bother the programmers there at all... Programmers do not decide which features and capabilities should be added to an operational commercial program. Management does that. 1) Irregular dates... BC is not regarded as within their realm of real... that is, they do not want to deal with it... since much of history is before 0 AD, this makes inputting data a real pain as one must continually deal with the pop-up of "Irregular date" which cannot be turned off (re Tech Supprt)... And when using a tag, this pop-up continues to stay popped up until rapidly clicked for 4-5 times before it will allow one to return to the detail screen... I agree, except there was no year 0 AD nor 0 BC. Three-quarters of human history or more was BC. Over 1000 people in my database have BC years. 2) There are nasty problems with dates from 0000 to 0099... here one meets the definitely unfriendly "Fix Century" pop-up... once again it cannot be prevented from popping up, and must be rapidly clicked for 4-5 times before it will allow one to leave the tag screen and return to the detail screen... try to input a date range, say 0021 to 0029, and it inputs it as "0021 to 0021"... so, one has to input it as "21 to 29" which results in the nasty FIX CENTURY pop-up! Furthermore, user entered numbers with leading zeros should not be treated differently than numbers without leading zeros. Also, there was no year “0”, probably because there was no Roman Numeral for “0”. Now, being no idiot, I do not need nasty pop-up reminders of the nasty TMG failure to deal with BCE dates and 0000 to 0099 (Fix Century) dates... Though I agree in principle, there is no need to be contentious.3) There are problems with the RELATIONSHIP CALCULATOR freezing the program... apparently with a large database (mine for now is about 18,000 relatives) it can take a long time for the program to calculate relationships that can be quite extensive (this is pretty cool on the few occasions when the progam does not freeze up on my 3GHz, 1.5GB RAM machine); however, when dealing with ancient ancestors (in my database), the program often quickly freezes and I have to do a control-alt-del to end task and dump out of the program (despite using the number of generations option to reduce the number of generations; if left at 250 gens it can kill it as well). I’ve had this problem, also. Usually setting the max. number of gens. to 32 or less will prevent this hang-up (integer problem?). My database is over 72300, 7600 images, mostly relatives, but not all. I use Windows XP, 0.5 gig RAM, 3.4 GHz. The dataset SQZ backup file is over 143 megabytes. Another problem is that when, on occasion, the relationship calculator gives me a long list of relationships (such as, for example, King Robert I of France who is my 27th to 37th ggf, 27-30th gguncle, 1-10th cousins, 27-37 times removed) there is no way to drop and drag the results to the individual pages (person, tag, exhibit), nor is there any way to have the results sent to a file... it just sits there on the screen; I have tried to use Ctrl-C and other methods to get it, but none work... Tech support questions why on earth I would want to do such a thing as put the information in the person's record... I could write it all down (at times there are 30-40 or more entries) and then type it into a TAG note screen, but with THOUSANDS of persons in the file, this is no fun... In my opinion, ancestors trump aunts and uncles, who trump cousins. In other words, if someone is an ancestor, it makes no difference if he is also (and probably is) a cousin, too. Since I’m my own cousin many times over, I don’t want to see the details on how I’m related to me (just being facetious). An option to trace multiple lines of ascent to an ancestor, however, would be a great feature. 4) There is a problem with the PREFERENCES-CURRENT PROJECT-OPTIONS-AUTO RELATIONSHIP option... This is a cool idea, but not well exeuted... It gives a relationship but unfortunately it is apparently the first one it finds... So, for example, if you are the focus person and the other is a ggf many times over and a cousin many time over, the options will list something, but it does not tell you all the relationships; it can give you a minor one and not a major one (such as 24th great-grandaunt and not 24th great-grandmother)... I don’t see how this could be implemented. For example, I have a g…g grandfather born in 1575, that I descend from via 42 lines. Where would you put all that generated data. It would also take 42 times as long to calculate. I don’t have any idea how long Auto-Relationship takes to run. I start an update when I go to bed, it is finished when I awaken. SUGGESTION: Be kind to us poor genealogists: 1) allow the user a "delete message" option for both FIX CENTURY and IRREGULAR DATE pop-ups, 2) fix the 0000 - 0099 range problem, 3) have some faith that when Ithe users puts in a date of, say 0015, that this is what was meant, and not assume that they somehow have the WRONG CENTURY (what prompted this TMG quirk is beyond me), 4) realize that BCE dates are real and deal with them in a program... TMG seems obsessed with the need to have numbers for their statistical routines (hard to subtract an AD date from BCE date), ](not if BC years were kept as negative numbers, but then you have to add one to compensate the answer for “the no year zero fact” when dates cross between AD and BC) but because some have THOUSANDS of ancestors who have BCE data, it would be nice to easily (no nasty "irregular reminders") input BCE dates, 5) fix the freeze problem with using the relationship calculator with many generations, many relationships, and many persons, 6) use a report definition screen to use the relationship calculator that permits different output options, and 7) change the PREFERENCES-CURRENT PROJECT-OPTIONS-AUTO RELATIONSHIP output to include ALL relationships (option to set the number of generations) with the focus person. I agree with most of your points. TMG personnel treat all members of this forum with total respect. They deserve total respect from us in return, even when they disagree. Best wishes, Mike Talbot

How do users handle BC dates in TMG? There is also difficulty in entering 2 digit AD dates. Is there an elegant way of entering BC dates and pre-100 AD dates available? planned? Thanks, Mike

Yes... I also didn't mention Babylon, Persia, Pontus, Phoenicia, Carthage, Selucid, Israel, Macedonia and many other places important to me. A professor in Ancient Greek History (my friend and in-law) was ready to buy TMG but decided against it when he discovered that it didn't handle BC dates. Except for 5 generations of his ancestors, the many and only dates that he had to record were BC. Several yeaes ago, I settled for spending weeks hand-fixing my GEDCOMed TMG ancient folks to TMG "non-standard dates." My old share-ware genealogy program the "Family History System" handled negative dates and calculations, just fine and was adequate. The only rubs were that FHS was limited to 32767 people and had no organized method for keeping references. Best wishes, Mike Talbot

Select a grandparent of the person and then do a "Descendant Indented Chart" or a "Descendant Narrative Report". Click on options and set the number of generations for the level of cousins desired. Select "print and save." Repeat for other grandparents, as desired. If you select print to file of a supported word processor, you can then hand edit where desired. I hope this is what you want. Mike Talbot

I respectfully disagree. We agree that you have acurately defined a family. A family group, by long tradition, consists of a Subject, all Spouses of the Subject and all Children of the Subject. TMG recognizes this definition by displaying the same. The only difference that I propose is the format. Loose the redundant displays of the major part of the Subject's data which can be quite lonnng. Best wishes, Merry Christmas and Happy New Year, Mike

Ahnentafel Report Index: Please. Provide an option to Index the Report by Ahnentafel Number, not page number. Is there a way to do this, now? I’ve never seen a professional publication where there was not an alphabetical index which pointed to the Ahnentafel Number, thus leading the reader to a specific person instead of a page containing 30 or more people. Thanks, Mike

Holiday fun with TMG and VCF. Here are 2 examples of charts that can be synthesized from multiple (less than a dozen) TMG-VCF charts in little more than an hour (once you practice). One composit chart shows my 4 grandchildren (top and bottom, left side), 2 grandpuppies (center) with my 3 kids and their spouses plus 4 more generations of ancestors. A total of 6 generations, sort-of, on letter sized paper. The other chart has an 11 generation direct-line of descent from one person of interest to another (down left side of chart) and then a standard 5 generation chart on the older person on interest. That’s 15 generations (again, sort-of) on a sheet of paper. The charts each fit on letter size paper and can be exported to JPG then e-mailed. See attachements. Merry Christmas and Happy Other-Things, Mike

Please, would someone comment? I find page numbers in an ahnentafel index to be most unsatisfying. It's one of the few issues that separates TMG from genealogical Utopia. Thanks, Mike

This is just a plea for more comments. I do like my Romans, ancient Greeks and pharoahs. Thanks, Mike

My opinion and recommendation: Unlike eggs, it is best to keep all of your genealogy data in one basket. To me, each of my ancestors at a given generation level is as important as any other at that generation level (if you don’t consider DNA testing). My recommendation is to keep a TMG single master dataset where you perform all additions of persons, lines and editing. TMG Focus Groups and reports make it easy to create other datasets or reports with just those named “Smith” and/or have some other common attribute recorded in each person’s record. It’s always much more difficult to combine datasets. You will always have the result of duplicate people and missing linkages when you combine data sets. These will have to be fixed by hand. I learned this the hard way. My first genealogy program (1985) was limited to 32767 people in a data set. With foresight I set up 2 datasets, one for Louisiana and N. America and one for Europe, figuring there wouldn’t be that many connections. Well there weren’t, but…. Half the things I wanted to do required people from each dataset. Many people then wound up duplicated in both data sets. This was a nightmare to keep up-to-date. I switched to TMG eight years ago since my European data set was nearing 32000. The restriction of 32767 persons per data set was now gone. I combined the data sets into one with over 40000 folks and life became much more fun. However, to my chagrin, I still find a duplicate person or missing link now and then, to be fixed by hand. Don’t get caught in my trap. I’m almost free of that trap after 8 years, (genealogy) life is fun again. Conclusion: A single master TMG data set is the way to go. Multiple datasets are great tools for temporary spin-off focus groups and for data researched and compiled by “other people.” Good luck, whichever way you choose, Mike PS: I now have 72000 people in one dataset. It’s still easy to find the person that I want or spin off a focus group Gedcom or dataset for a relative, in-law or friend.

My stated opinion was clearly confined to my use of TMG and not intended as a phylosophy of life in general. When you look at a woman's TMG detail window, for instance, you see each of her husbands' surnames. Of what value is it to repeat her given name(s) with the surname of each husband. It's deja vous all over again. Seeing 100 Ann Smiths, all in a column, and aiming a mouse is confusing, especially if one is not blessed with the manual dexterity to properly aim a mouse. It is a bit easier if a goodly % of the Ann Smiths weren't there (marked or not). If you enjoy married names and approx. 25-33% larger project index tables, by all means, please use them. If I have inadvertantly stepped on a sacred cow hoof, I did not mean to do so. Please forgive me. Best wishes, Mike

I use MS Word 2000. All of my TMG text reports are output, there. I do some editing on over 90% of TMG reports. Usually something needs to be explained or something ugly needs hand editing. In some cases an error can be corrected without going through an hour of regenerating a long ahnentafel. Another advantage is that you have the MS Word doc on disk, as backup. Genealogy wouldn't be fun without editing reports before printing. To me, MS Word or its equivalent (I don't know of an equivalent) is a necessity. I've found no use for Excell with TMG, so far. Best wishes, Mike

I too work mostly in the "way back" where complete dates are rare. Married names just get in the way, "back there." I can't think of an instance, even modern, where married names might help genealogical research. Consider that you are looking in the project index for Ann Smith, b. ca.1570. Now pretend there are hundreds of Ann Smiths in your project, 4 or five of them are born ca.1570. You click on one and discover this is really Ann Jones who married a Smith. Well, another few wasted precious moments from research. If you set up your "TMG views" properly, the husband's name is always there when you're looking at the wife's record. So there is no need to clutter your project index with 25% or so more names in the project index that only confuse selecting the right lady. Why not view a woman's birth name as her only name and think of the husband's surname as an intrinsic title? Of course if you insist on married names, TMG has them waiting for you. Just an opinion, no offense intended, Mike