Pierce.Reid

Darius The devastating failure of a financial institution, Freedman's Bank, designed to help former slaves, has now yielded the greatest repository of lineage-linked African American records known to exist. The 480,000 Freedman's Bank depositors gave information documenting three generations of slavery which gives their descendants, an estimated eight to 10 million African Americans, precious clues. Further information about this valuable information and where it may be purchased (in 2001 its cost was $6.50, including postage) can be located at: http://www.ancestry.com/learn/library/arti...px?article=3508 The New York Genealogical & Biographical Library also has those records documented in a compact disk (CD-ROM), Freedman's Bank Records [call number E 185.2 F75 COMP. DISK]. It is a non-circulating library. If you are unable to obtain the CD-ROM for your own use, you can probably make contact with someone on the AFRICANAMER-GEN-L@rootsweb.com, which Teresa referred you to, who lives near the library and who may be able to do some research for you. Good luck in your quest. Norman Another source of Freedman Bank records is at Family Search Labs, at: http://search.labs.familysearch.org/recordsearch/start.html# Note part way down the left column, under Court and Legal Records. You can get images of the application forms filled out by depositors. Note that this bank seemed to not discriminate on the basis of race. There are many whites, including European immigrants, who had accounts. The information on the application form can be very useful for genealogists. The FamilySearch Labs site is a beta site for prospective enhancements to FamilySearch. Like FamilySearch, it is free. It also has the 1900 census and a spotty collection of other records. We've been lucky to find a number of useful records on our families. If you use this site, send feedback on what you liked and did not like about it to FamilySearch. Pierce

Helmut, I've used both an external hard drive (both direct connect and through a home network) and a flash (thumb) drive, connected through the USB port. Generally I find that response time working off a drive connected through the USB 2.0 port or the network is slower than working off the internal hard disk. And I still find many TMG steps to be slower than I expect, even using the internal drive. But then I am used to using Ultimate Family Tree, which seemed slow on the computer I had 10 years ago, but just flies on modern machines. In any case, how you feel about the speed issue depends on what you are comfortable with and the benefits you see in using the slower methods. Pierce

Sue, What is your experience as to speed? I've found other programs run slower if their database is on a thumb drive, even a USB 2 drive, rather than a real hard disk. As far as backups are concerned, I suggest keeping a number of backups. I seldom delete any, although ancient ones disappear when a PC goes to the great computer room in the sky. I've had a couple of cases where I had to restore several generations back to recover from a data problem that was not detected for a while. Pierce

Linda, I have not encountered any slave individuals in my data, so I have no experience in what conditions you might want to report. However, a good starting point is to decide how you want the text to read. Write out exactly what you want your report to say. That includes deciding which individuals you want the information reported for. Decide which data elements might change from one tag occurrence to the next. The key individuals and maybe the date are obvious ones, and maybe the location. These have codes that are used in the sentence syntax. Other variable information can be built into sections of the memo field, and/or you can use the memo field to add any additional text that is of interest. Note that if you want to report slave information in several different ways, you can define several tag types to get what you want. Once you know how your want your text to read, you can replace the parts you want to be changeable with appropriate variable codes. That may be beyond your present knowledge, but if you give examples of what you want, you will get suggestions from the list on just what you need. Then you will be using more of the power of TMG to produce the reports that you want. Pierce

Jim, Is this the best that TMG can do when producing these error messages? (I suspect it may be, if they are triggered by some FoxProx error condition.) Back in my programming days, I tried to provide as much detail in my error messages as possible, specifically giving relevant variable values and the condition I was testing when my program encountered the error. If the error was triggered by a system fault (e.g. a divide by zero), I would try to capture the error before the system produced it's generic error message, so I could give a more useful message. (This actually was more to help me as the developer, rather than some other user.) For example, for the first message, what was the operator and type values, and what tag was being processed? For the second, what statement was being processed when the syntax error was encountered? I suspect it was either a statement that is fundamentally wrong or one that is invalid when certain variables have "unexpected" values. More complete error messages might point a user to a problem in the database, or make it easier for developers to locate the error without having to have the user upload the entire database. I don't know FoxPro or whatever other packaged software Wholly Genes uses, so these suggestions may be impossible with current technology. However, such cryptic messages from the system certainly frustrates users who encounter them. Pierce

Terry, Would resetting the computer's date to before the 30 day expirey date allow a backup to be created? But if you do that, reset the date to the current one so you don't confuse other programs on your computer. Pierce

Krystina, The advantage of specifying a witness role of "Informant" is that you can quickly link to the witness's individual record from the death tag, without having to do a search for that person (if you have just noted the individual's name in a memo or citation text). In addition, the informant's individual record will show that he/she was "active" (alive) after the deceased had died. I like to have everyone associated with an event tag to be linked with a specific role. If there is no appropriate role for a tag, I create a custom role for the tag. Pierce

The standard Wholly Genes response is "the upgrade will be announced when it is ready, and not before". And while we may eagerly await an upgrade, I think most TMG users appreciate the logic behind that policy. The best you can do it ensure that they understand your problem and frustration. If you are lucky, you may get a pre-release of the program modules that cause your problem, to ensure that it does work for you. They did that for me once, but I was told to remove the temporary fix when the formal upgrade came out. Pierce

Andy, There is one TMG feature you probably want to keep in mind if you are continuing to enter data into FTM, but plan to convert in the future. TMG has a concept called Tags, which can be used, among other things, to specify events. An event Tag is generally associated with one, or maybe two, individuals, called "Principals". However, you may attach any number of other individuals to a tag as "Witnesses". A "Witness" may not actually have "witnessed" the event, they may even have been dead at that time, but somehow they are associated with the event. You can also specify the role each witness had in the event. The standard person view shows all events that the person is associated with, including those the person was just a "witness" to. For example, you have a census "event" (i.e. the recording of the persons in the household on the census day). Your "Principal" is likely the Head of Household, although it could be another person more directly related to you. However, you want to record the presence of everyone else in the household. You can attach each one as a witness to the same tag, assigning each the appropriate role, e.g. "wife", 'son", "servant", "lodger", etc. To get the same effect in FTM 2008, I believe you would have to define an event for that census for each person in the household. To be really rigorous, you should also define the source of your census information for each one. In TMG, you would have only one event tag, appropriately sourced. You can use that tag to go from one individual in the household to another, just by clicking on a few links. So as you are entering data into FTM, think about how you would do it differently in TMG. If you play a little with TMG you will get a better feel of your information is recorded there. One thing about Wholly Genes is that they do not announce a new feature until they release the feature, whether it is a simple bug fix or a major upgrade. (Although they came close to giving a release date when they indicated the release 7 would be out by "the end of the year".) I believe that FTM 2008 has a significant change in the data base structure from previous releases, which presents a bigger challenge to Wholly Genes staff. But they will get there; FTM ass too big a market share to not support it. Pierce

Enter one or two of them as Principals, then enter as many others as you like as Witnesses. Terry didn't mention the concept of "roles" that Wholly Genes added to TMG to entice UFT users to convert - and may did. TMG originally had Principal roles (maximum of 2 per event tag) and Witness roles, which could be anyone else you wanted to associate with that tag. An obvious example is a birth tag, where the "child" was the Principal and the parents were both Witnesses. For a marriage tag, the bride and groom were the 2 Principals and you could link all the attendants, etc. as Witnesses. A Witness does not have to actually "witness" the event. For example, for a Probate tag, you could link all the beneficiaries, even those who had died before the Deceased died. Roles allow you to identify what part a person played in the event, such as Best Man, Maid of Honour, attendants, flowergirl, minister, etc. You can define a "role sentence" for each role, which puts into English (or whatever language you can use) what part they played in the event. The main Person view shows all the event tags that individual has been linked to, as well as the relationship of the Person to the "principal" for each tag. This gives a sort of time-line for the person's life. You can open these tags to find out the details of the event as well as who else are associated with the event. You can then jump to any of those individuals. All this when you link each of the "witnesses" to the main tag. Unlike other genealogy database programs, you don't have to define a separate "event" record for each person at the event. I found having multiple persons linked to an event in UFT to be a powerful feature, and I am glad Wholly Genes added the roles, to provide most of the UFT event structure to TMG. Pierce

Foxpro is hardly dead - it seems to work quite well for TMG. In fact, Foxpro under Win 3.1 is not dead, in that it still supports UFT under Vista. Just because the vendor is not making further enhancements does not mean it is not a very useful tool. One powerful feature, in my opinion, in both TMG and UFT is the ability to link many individuals to the same event record. If you have many people involved in the same event, you don't have to duplicate the event for each. Simply assign each to a role in the event/tag. It is such an easy way to fill out the chronology of a person's life. It also allows a more powerful method of navigating through your people. It seems such a logical concept, once you have used it for a while, and I don't see why it has not been taken up by other vendors. But I guess most genealogists don't miss what they have not tried. Pierce

Roy, The amount of cleanup of source information you need depends on how satisfied you are with whatever comes through the Gedcom. Or maybe just as important, how satisfied others would be with the way the information is presented. Note also that the proper source information for data from Ancestry should include the full archival reference, so someone else could use another repository (e.g. another on-line census provider, or the Family History Library, or the government archive) to find the same record. I have never considered using someone else's source format unless I reviewed it and agreed it is as good as I could produce. In any case I would manually put the source information into my data base. I would never just dump someone else's data into my data base. All the data goes in manually. At most, I would copy and paste selected words from another file to put them in my data base. Pierce

I've noticed that if I press the Ctrl key and rotate the scroll wheel on my mouse, TMG 6 tries to close and asks if I want to backup my database. Pressing Cancel on the question window does not close the window or stop the operation. When I respond "No", TMG closes. The Ctrl key plus the mouse wheel can often be used to enlarge or shrink the display font of a Windows application. While I am not surprised that this feature is not available with TMG 6.12, I was surprised at what that operation did. Is this a intended "feature" of TMG, or is this an operation that was not designed into the product and just happens to force the application to close? Pierce

Since these tips were posted, computer hard drives, home networks, and file servers on the web have provided much greater storage capacity. Now it is quite reasonable to keep many, many backups. Home networks make it easy to move backup copies to other computers in the house. USB Flash Drives make it easier to transport backups to the computers of relatives and friends. Web sites are available for off site storage. All these tools should be used to protect your data.

Staying current with respect to software is not always the best solution for everyone. I am still using UFT as my main genealogy program. It was designed to run under Windows 3.1 but still runs well under Vista. It has several features that I use regularly that are significantly better than TMG, and I have requested a couple of them on this forum as well as to Bob personally. Although I have not downloaded v 7 yet, I have seen no sign of them in the "new features" lists. Another benefit of using obsolete software is speed. As TMG expands, it seems to keep the same, fairly slow, response time on the then-current hardware. UFT had the same speed issues when it first came out, over 10 years ago, but with current hardware, most commands (change of focus person, searches, event displays, etc) are almost instantaneous, as is initial startup. Another benefit of such old software is the ability to execute UFT off a regular USB Flash Drive. That means I have regular access to all my genealogical data in my database, even on many computers that are locked down to reduce the chance of user modifications. I have made good use of TMG for several charts and reports. I have also been modifying my UFT data to improve the import into TMG. However, much of the data entry that I currently do in UFT would take significantly longer in TMG, and I would loose several features that I find quite useful. I fully expect to fully move to TMG some day. It may be when I have to get a computer with an operating system that no longer supports UFT. Or maybe Bob will add the missing features I think are important. I would even put up with the slower response times to get some of the nifty features not in UFT. However, for the time being I will just experiment with TMG but stick with UFT. Pierce Pierce

David, I think I know a bit more about networks and VPNs, but not enough to want to try setting one up, especially if you are relying on the quality of your data base on such a setup. I think you will have to recruit a "geek" who is familiar with the technology to set you up, and to configure your other users' computers, and define the rules for using the system, and to handle the inevitable technical problems. You will also have to define and try to enforce some basic data entry standards, as each person is likely to have a different idea how some data should be entered. I'm not sure to what extent you could "partition" your database so that each person can only update certain sections of it. If you can define a filter that effectively limits the part of the database that an individual contributer is responsible for and can modify, then you might be able to do a bulk update. A contributer would start with a specific version of the data base, update information on his section and then do a subsetting of the data base to select his updates. When you receive the updated segment, you would filter out the old version of that segment and merge the updated segment. Obviously there would be problems at the edges of each contributor's segment where they link with other segments, and you would have to have a method of identifying those areas and possibly updating them manually, as you do now. One advantage is limiting where a contributor can damage the data base, either due to human error or to a system error. I'm not sure if TMG filtering has the capability of being used this way, but I have a strong impression that it is a powerful capability. Pierce

Bill, I agree that a name index is a valuable part of any proper genealogy report. If you have tried using the index codes in Roots IV/UFT, you will find them a bit different to use in TMG. UFT had you put the individual's number in the text fields if you were going to have index references within your text block. TMG has you inserting the actual index values into the memo fields. If you want one entry in your document index to refer to both individual references from the role sentences as well as within memos, you need to ensure that you enter the individual's information in the index code in the memo exactly as TMG will format its index code: Last name, given names, and possible birth & death years. This is not too much of a problem if you don't create any index codes in the memo fields until you are about ready to produce your final report. At that point you have presumably finalized on which of the various index formats you want, e.g. do you want to add the birth and death dates to the individuals' names (especially valuable if you have a number of individuals with identical names - and I think we all have some of those) and people's names in your data base have been "finalized". If you want to add index codes to your memo fields as you create them initially (usually an easier way to do that), then you could have a problem. If, for example, you describe a will and indicate various beneficiaries and executors, you may not know exactly who the individuals all are at that time. You could still create the individuals in your data base, but you might not know their full names or their birth and death dates. Later research could fill in that information, but then you would have to go back to the will description to correct the data you put into the index term initially. You may well have to update the index information several times before you get it right. And you won't know if you have it right until you create a report with the index terms, and you proof read all the index terms. Another problem could be if you change the format that you want TMG to create index terms. It is best to decide on a format initially and stick to it, both for creating index terms and for creating reports. The UFT method of using the individual's number means that the latest version of a person's name and dates are used when you produce the report. The down-side to the UFT method is that you cannot easily provide different formats of a person's name, such as nicknames or a woman's married. UFT juse uses the birth name that you have entered. A year ago, I suggested to Bob Velke that an additional syntax for index information in memo fields be allowed that uses the individuals' numbers. It seems like a fairly simple enhancement, as TMG must create index references for individuals referenced in role sentences. At the time I presented my idea, he hypothesized possible confusions if people had multiple data sets within a project. Since I don't envision wanting to use that feature, I don't understand it enough to see what the problem might be. In any case, those who want to create index references using individual numbers would just have to be careful where they use them. It would certainly make it easier to get a consistent index for Journal type reports. One other problem you will notice if your are converting a UFT database with index references in text blocks, is that TMG's Genbridge import program just creates index entries of the format Last name, given names. There is not an option to have Genbridge add the birth and death years, if that is your UFT standard. (These comments are for TMG 6.12. I did not see any mention of index codes in the brief description of TMG 7 that Bob has published, so it seems my suggestions have not been included in the upgrade.) Pierce

Mark, It may be a bit late for this suggestion, but do you have backups of your database? Ideally, you will have made frequent backups, and you kept them all in separate files. That way, if you create a data problem that you don't notice for some time, you can review previous backups to see where the problem was introduced. In addition, if you know the data was correct in a particular backup, but restoring that backup gives you the same problem, it suggests you have an incorrect TMG setting for what you want to see, rather than missing data. A couple of times I have had to restore to an older backup to correct a problem, so I am glad to have lots of backups - on several computers. Pierce

One caveat on dates. If you enter a date that is not in one of TMG's pre-defined date formats, TMG will not be able to calculate a sort date. The date will be treated as an "irregular date" and will only be used in text type reports, such as Journal reports. It will not be used to sort tags or printed in reports that have limited space for dates, such as box charts. For irregular dates, you can manually enter appropriate sort dates for sequencing the tags, but they still will not produce a printed date in some reports. This is a minor complaint I have with TMG's date structure. They could, for example, have a more intelligent algorithm for recognizing a wider range of dates. However, the format for printed reports will then translate what you input into your choice of one standard format that is used throughout the report. A better solution would be to have a third type of date field, corresponding to TMG's standard date format, which you could set to what you want for reports with limited space for dates, such as those box charts. But that would require a fair bit of new programming by the developers, and there does not seem to be much demand for this feature, besides me. Pierce

Judy, 1. I think the various sites with TMG tips will be available for a long time, so you just need to know where to find them. Try your browser's Favorites/Bookmarks list. 2. If you want your own copy, put them on your computer, not in paper files, so you can search for them by key words that are in the tips themselves. Then you don't have to think up suitable terms for your filing cabinet. But don't forget to back up the tips folder along with other valuable computer data. Have a happy holiday playing with your genealogy. Pierce

The product we are using is The Master GENEALOGIST. Bob has a preference of wanting to follow the genes, the blood lines. Yes, we can use TMG to keep track of family history and even report much of it fairly correctly if we wish. But you are asking to go a fair bit beyond blood lines with your proposed Family Journal Report. And there is the question of how far you want to go with this family history thing. For example, do we include the children of the wife's previous husband's first common-law wife, etc.? Those children could have lived in your relatives family. While such occurrences are rare, the program should have a policy for how it would handle the unusual family groupings. In any case, I support the idea that TMG should make it easier to look at and report Family History, as opposed to strictly genealogy. Including ways to properly report adoptions, half and step siblings, etc. would, I think, be a useful improvement to TMG. Pierce

Mike, Most event sentences have an explicit date reference. It is reasonable to want reports to record what was in the original document, assuming the reader can understand that date format. Alternately, some people may want the report to record the date in a standard format (the way TMG currently does). Or, some people may want the original and the standard date formats reported next to each other (e.g. "on Michaelmas last (29 September 1801)"). With three dates, as with UFT, journal reports will report the date anyway you want, simply by entering that text in the Free-format date field. UFT has enough smarts to convert a wide range of "normal" dates into the correct structured date. But you can change that to something you think is more appropriate, or if UFT cannot figure out the correct structured date. Of course, you would want a standard structured date for reports such as charts where arbitrary text would not fit. Putting the date in the original format into the Memo field might make the sentence more awkward than you would want, and/or require modification of the sentence structure each place you want the original date to be reproduced. Sure, you can make TMG produce any text you want for a tag, but having a Free-format as well as a structured date could eliminate or reduce the customizing required. And reducing work is what computers are all about. Pierce

All these different ways of specifying and calculating dates points to what I consider a significant limitation of TMG around dates. Good genealogical practice is that you should report dates as you find them. However, as this date history lesson has shown, dates as originally recorded often are not compatible with current date schemes. Trying to standardize date formats the way TMG does means that dates may appear in TMG reports in a form incompatible with the original record. You can make a date "irregular", in which case TMG only reports it as you entered it. However, then you do not have a date you can use for calculations. You can specify a Sort date but I believe that is just used for putting tags in sequence. In any case, the sort date does not appear in any reports. Many of the dates we encounter that are some variation of Julian, rather than the current calendar, are only a few days off. They are usually adequate enough for showing just the year, or for calculating an age in years. But they are not as accurate as genealogists often like to be. TMG really needs a third form of date. Ultimate Family Tree provides three date fields: a free format date that can be anything you wish, a structured date, and a sort date. For most dates we input, UFT can usually figure out the correct structured and sort dates automatically. However, you can change the structured date and sort date independently of the free format date. TMG insists that you choose either the free format ("irregular") or the structured date format. If you choose the structured date format, all dates in reports will appear in one standard format (our choice), which may not match the way the date was recorded. In the UFT database, you can record the date in the format in the original record (or any other format you want). If you want to convert it to the current calendar, you can apply the appropriate conversion algorithm for the time and place the original record was created and put that in the structured date field. Or you can enter a date that is more compatible with the original record. You can enter a sort date that is consistent with your other dates. As a somewhat extreme example, the original date may have been in another language and that is what you want to report in text reports. You may want the structured date to reflect that date. If, for example, that date used the Julian calendar, you may want the sort date to be compatible with the current calendar. In UFT, that scenario can be handled just by filling in the appropriate date fields. In TMG, you might be able to do the same thing by modifying the role sentences for each tag occurrence, to hard code the date as you desire it reported. If you have several role sentences you want that date in, each has to be modified separately. That date is not part of the basic database, but rather is off in the role sentence(s) customized for that particular tag occurrence. The lack of a third date fields is one of the things that frustrates me about TMG, and is fairly high on my "wish list" of features I'd like to see. Pierce

How much loss you can tolerate depends on what you plan to do with an image. You might want to look at a photograph in some detail, or select out just a part for reproduction, so you probably don't want to loose any detail. For a document image, you just want to be able to read what it says. For example, a census page has fairly broad pencil lines, and as long as you can read the words, greater detail is not needed. As well, if the image is taken from an old, somewhat blury microfilm image, keeping all the blury detail may be of little value. You can generally save them in a file of several hundred kilobytes, rather than megabytes if you save them with no loss. Of course, some of the later American censuses have a lot of detail, so the files are likely to be larger. Larger files take more time to load and copy, and you cannot keep as many on your archival media. That might mean more documentation about just what part of a directory is on each of the CDs or DVDs that you are saving. Keeping unnecessary image detail when it creates more external work (i.e. cataloging your physical media) may not be a useful trade-off. Pierce

I still have not committed my data to TMG. I've done a number of trial imports from UFT to TMG and have made a number of changes to my data to be more compatible with TMG. There are quite a number parameters that have to be given to the Import wizard, starting with the source database type and location, and including how I want various events/tags handled. I would like to be able to have the import parameters default to the ones I used last time, or some previous time. That way I could quickly repeat an import after changing the data in the "foreign" database, or I could examine the effect of changing one or a few parameters, and be sure the others were the same between two runs. Is there a way of saving the import parameters between runs? If not, I would like this feature added to the new version (if it is not already there). Pierce