elevator

I have quite a few family marriages for which I have rather extensive guest lists. Some of these have 400+ individuals with a large number of them being family members recorded in my family tree. Normally when I enter Marriage tags I only record the wedding party such as Groom, Bride, their Parents, Groomsmen, Bridesmaids, Best Man, Maid of Honor, Flower Girls, Ring Bearers etc. as witnesses. I have for a long time considered creating a witness role called Guest which would enable me to record all guests to the wedding. (As a side note I have considered the same for baptisms, burials, etc also). The reason I want to do this is that it creates a more complete picture of which family members would attend such functions and creates a better "social map" of the family. However, what I want to know is if anyone is doing this; if they are doing it by adding these people as witnesses to a particular tag or if there are any other ways of doing this? Also is there a problem with adding 200+ (sometimes up towards 400) witnesses to a single tag - as far as program limitations are concerned? Thank you for your help, Ken.

Thanks again for your suggestions Terry. I am going to create a new project from a sampling of the real one and do some testing on that.

Terry, Michael, Teresa; thank you all for your replies! I think I am ultimately going to go with Terry's suggestion of making a separate tag for guest lists. As far as my reason for doing this is partly that I have a very widely spread family - geographically speaking - and special occasions such as Marriages and Reunions (and in some rare instances milestone birthdays, baptisms and burials) may be the only time when social interaction between certain family members or branches of family members take place and several family members have voiced a wish that we somehow could record information such as date, place, and reason for the event as well as photographs taken at the particular event. I would only include that part of the guest list which is in fact family - and most of these people would already exist within my family tree database - meaning that the extent of the work would be limited to adding witnesses to tags which I can do at a rate of about 1 every 5-10 seconds - robbing me of about 15-30 minutes for a 200 person guest list (plus the time it would take to add in the photographs - which I would be categorizing in some manner anyway). Another possibility that I have played with is picking certain family members that is of particular interest to me (such as direct ancestors or descendants and maybe cousins and the like) and record their presence on any family marriage guest list. This would drastically reduce the work as I would not need to record entire guest lists of say 200-300 people, but maybe only a third or less. The side effect of that would be, of course, that I loose the ability to record social interaction with the distant family members which is really what I wanted to do in the first place. So, yes, I am struggling a bit with the necessity of this whole project, but at the same time, we're as of yet not talking about a large quantity of events (in the vast majority of events I have no documented guest list), probably something I could finish in a few days. Anyway, thank you all for your help. If I ultimately decide to do it - I will do as Terry says and go with the separate tags.

Jim: Thank you for your reply. I have encountered surety problems with at least event tags and name tags. So far, I have not seen problems with relationship tags. I can definitely confirm that the problem is still evident as I run VFI about once a week and I've had v7.03 installed since it was released (and no problems have been reported by the VFI procedure).

It certainly makes me feel a lot better to know that it is apparently just a display problem. My initial fear was that data was being lost as well, but so far all the tags I have checked all have their citations in place with the correct sureties; they just don't always display correctly on the detail screen. Like Teresa, while I am happy to hear that none of my data should be compromised by this bug, it certainly is an annoying bug! Thank you both for your help. Ken.

The easiest way is to add an exhibit to the source itself (not the citation). To do this: 1. Open the Master Source List (Tools->Master Source List) 2. Add a new source (or edit an exisiting one) 3. Click on the little camera in the upper right hand corner of the dialog (this will open the exhibit log) 4. Click on the button marked "Add" 5. A file picker dialog will open, navigate this to your exhibit, select the exhibit and click open. 6. You can then right click on the exhibit and choose "Properties" to edit data about the exhibit 7. Close the Master Source List 8. On the Detail screen under the person tab, open the tag you want to add a citation to 9. Click on the plus button under citations to add a new citation 10. Choose your newly edited (or added) source to cite. Hope this helps. Ken.

I am sure there are others far more qualified to answer your question than me; but I have used TMG for a very long time and also tried a variety of other programs. One thing is clear to me: as far customizability, source tracking and ability to record any data, TMG is far beyond any other genealogy program I have tried. You can make TMG register any data you can dream of, and it does so just beautifully. I have also found that the reporting and charting engine is at least on par, and in many instances better, with other poular genealogy programs out there. I have also found that (on my computer at least) TMG is very stable and I have only had a few crashes after upgrading to TMG v7, none of which has resulted in data loss. I know there have at times been rather heated discussions about the FoxPro platform. It is a dying platform and the next generation of Windows operating systems may require a migration to a different DBMS. Also, the program is tragically lacking in its multiuser capabilities and it is almost impossible for a team of users to collaborate on one single project, but many other solutions have that limitation as well. I have solved this problem by using another web based software for that part of my research and I find it works good for me. All in all, I firmly believe that at this time there are no better genealogy programs than TMG, as long as one takes the time to learn to use it's more powerful features. Ken.

I solve this particular issue the following way: if the death date is "23 Sep 1943" and the burial date is unknown, I set it to "after 23 Sep 1943". That way I don't get the warning and the burial tag is sorted correctly. My personal opinion is that I avoid constructing burial dates. For example; to assume that a burial took place in september 1943 because a person died the 23rd of that month, may not necessarily be true, because the burial may have taken longer than a week. But by setting the burial date to AFTER the particular death date, you're safe in all instances. Another way to solve the problem is to simply not include a burial date. Afterall, if there are no sources documenting the burial, why include it at all? I like having the primary church events such as birth, baptism, confirmation, marriage, death and burial included, but that is not always possible if there are no sources documenting that particular event. Hope this helps, Ken.

I have really no idea as to what the underlying programming language is for TMG, but I am convinced that IF it is VFP, WhollyGenes realises that, and is working to port whatever code needs to be ported. Point is; the program as it is now works better than any other genealogy program I have tried, and that was really the selling point for me. I don't choose my genealogy program based on which one "looks" the best, but rather the one that suits my needs. If at some point in the future ANOTHER program comes along that is better I will just switch. I am sure WhollyGenes realises this and will not leave it's customers out in the cold in 2010 or 2015 when VFP becomes obsolete. Ken.

I want to stress again that FoxPro is only the data access layer (the back end) and has nothing to do with the visual interface of the program (the front end). I think this is an important distinction to see: we can have an ultramodern program that relies on FoxPro (or Jet for that matter) as it's data provider. If you do programming in .NET you will see that there are numerous data providers such as Jet, ODBC, ADO, RDO, SQL Server, Oracle, etc. The use of ANY of these data access technologies does not in any way limit the interface. Just because FoxPro is used for data access, does not mean that the front-end needs to be programmed in FoxPro also. In fact, as far as I know, TMG itself is a C++ program (developers correct me please). Also FoxPro will be supported by all operating systems released by MS until 2015, so WhollyGenes still have a few years to migrate to a different RMDBS. What I like about the TMG interface is the freedom that you have. Most genalogy software have predefined screens, but TMG let you choose from a large number of interface elements and "build" your interface from scratch showing the features you use a lot and hide the ones that you don't use. So I disagree with you that the interface is old and outdated. It could use a facelift, but that's really all it would accomplish; a prettier interface would not add any functionality to the interface; just make it look better. That said; I DO agree that a change in database access layer is required at some point, and there are many discussions talking about just that. Ken.

FoxPro is as far as I know only the method of communicating with the database and has really nothing to do with the visual interface of TMG. While I agree with you that FoxPro is dead and maybe WhollyGenes need to implement a different data access layer, I disagree that the interface is in any way limited. The interface is extremely customizable, but lack some of the XP/Vista/.NET elements that make programs look more visually pleasing, and that may be what you are referring to. But the inference that TMG is built on "old" technology because of an "older" looking interface, may be deceiving; because even ultramodern .NET applications are free to use whatever interface models they want without sacrificing power under the hood. We have had this discussion many times, and I believe most people agree that TMG is not the most user-friendly or "pretty" application out there, but certainly has the power and flexibility to rival any genealogy application out there. If you are still choosing what application to ultimately settle down with, I would recommend that you spend some days (or weeks) to learn the program and I am confident that you will find that the features outweight the visual limitations. Ken.

I have a hispanic branch of my family as well and have experienced the same "problem" with how to register the information. I came to the following to conclusion based on talks with the elders of that family branch. To use your name as an example I would split it up the following way: Maria = Given Name Irizarry Y Feliciano = Surname De Rodriguez = Married Name (Surname field) Most people I have talked to seem to prefer keeping multiple last names together as this is apparently how it is done on most official documents. For example the convention of naming a child: <<firstname>> <<fathers last name>> <<mothers lastname>> it is common to treat BOTH last names as the last names for registration purposes. However, in newer times I have seen that the mothers last name of sometimes listed first and in THOSE cases, only the father's name appears in the last name field, while the mothers name appears in the middle name field of the child. Married names (i.e. De Rodrigez), names derived from marriage, should always be entered as a separate married name in TMG. I hope this wasn't too confusing; but to sum it up: 1. First name should always appear in the given name field in TMG 2. Married last names should always have a separate Name-Marr tag created in TMG with that name in the surname field 3. If BOTH mothers and father's last name is used for the child and the FATHERS last name is listed FIRST; both names should appear in the Surname field in TMG 4. If BOTH mothers and fathers last name is used for the child and the MOTHERS last name is listed first; the mothers last name should be put in the given name field together with the first name and the fathers last name should appear in the surname field in TMG. (as far as "De" is concerned, depending on your needs in terms or sorting, you may want to put that in the Pre Surname field in TMG) I am sure others might do it differently, but this is how I do it. Ken.

I agree with Mike. I use a custom tag called Photograph, which I will use in situations such as this. The good thing about using a tag is that in addition to witnesses it allows you to attach a date and a place to each photograph in addition to a memo. But of course I am sure there are situations when another, more robust way of linking several people to a photograph using the exhibit log would be desireable. Ken.

TMG, if adopted into a multiuser environment per your specifications, CANNOT be both provider AND consumer of the data. Warren Culpepper's solutions involve connecting via VPN, RDC or Terminal Server to the computer holding the TMG data and execute the instance of TMG on that computer. In a true multiuser environment data isolation is key. The data should NEVER be on the same computer where TMG is installed. The only way this can be done is by hosting the data on, for example, a Linux/Unix MySQL server (the free solution) or a MS SQL server (the expensive solution) and having TMG connect remotely to this server and consume the data provided by this server. The VPN, RDC solution can work for a few users, but in situations like me where I have more than 250 family members registered on my phpGedView website and at least 20-30 of them connect every day, it is easy to see how such a solution would be absurd. (If this was one VPN, RDC computer I'd love to see it run 20 instances of TMG ) Of course this is putting it on the edge a bit, but one cannot presume a program to be "multi-user" if in practice it shows that reliably only 2-5 users can connect simultaneously. All respect to Warren Culpepper, but if you can call TMG a multiuser program because you can VPN to it, then you can call any 32+ bit single-user program multi-user because you can VPN to those also. Even if you accept a solution using VPN or RDC there is no way this solution can be built upon to further develop what you in reality want: a multiuser collaboration suite, because if hosted on WhollyGenes servers, it would not be feasible to have people VPN to establish Terminal Server connection to their servers to access their data. Because if these limitations I cannot accept that TMG "works" in a multiuser environment. In addition to this, I still see some basic problems: 1. External exhibits are still stored with absolute paths wich makes migration anywhere a pain. The data must allow migration anywhere at any time without the danger og breaking any links between data and external exhibits. The way ALL multi-user application solves this problem is by storing external data using paths relative to a "root" location in the directory tree on the server (imagine load balancing scenarios...) 2. The database engine must allow for a server based data accessing layer. The use of VFP, MS Jet or similar in multiuser environments is ridiculous and must be replaced by systems built for this type of database access (such as MS SQL server, MySQL, PostgreSQL, even SQLlite). Such multiuser systems are made for multiuser access and allows the creation of user accounts and granular access control. I don't mean to play devils advocate here or shoot your idea down, because, believe me, I think it is an excellent suggestion and I would love to see it implemented. I just think that TMG in it's current state has a long way to go to that point. Ken.

Yes naturally, to seriously use some of the already existing online genealogical collaboration solutions out there, you would have to more or less abandon TMG unless you’re willing to deal with the synchronization issues or unless you have a project in which information can occasionally be out of synch just to be brought up to date at various points in time. For me it works great; I allow family members and other fellow genealogists working on the same line to add, edit and view information online, and then occasionally this information is entered into my personal copy of TMG. I assume my fellow researchers do the same thing on their end: that is; they have their own private genealogy program that they and only they have access to, and then we all have our “joint venture” so to speak online, where we come together to share research, thoughts and sources and then each one of us decides how much information (if any) we want to include in our own personal copy of the family research. But I can without a doubt see the usefulness of your suggestion, but the way I see it; it would be a two step process: TMG would HAVE to become a multi-user system. Currently there is no way for more than one user to share the data (and keep it synchronized). As far as I know, there is no way to put the data on, say, a server somewhere on a shared network and then two people with licensed copies of TMG accessing the SAME DATA at the SAME TIME. Such a feature would be tremendously valuable because it would allow collaboration through a LAN or WAN. The next step would be to move this multi-user functionality to a web server on WhollyGenes servers hold user data and a web interface to implement the solution you have in mind (if I have understood you correctly). I have no idea whatsoever about the inner workings of TMG, but I suspect that the data access layer of the application is rather proprietary and that a change of database access layer to interface with other database back-ends (say MS SQL Server or MySQL) would require more or less a complete rewrite of this particular code. I would love to see anyone involved in the direct development on the program to elaborate around your request because obviously I am the wrong person to do so. I can see the usefulness of your request though, and I support it wholeheartedly! I believe it is a long and costly way to go though from the current perspective. Ken.

Most of my users are notoriously technologically challenged, but it doesn't really matter because as long as there is ONE person on your team that is able to configure and get the program up running, the inner intricates of such a solution is invisible to the end-user. As such my partners are able to work on our common project without really knowing anything except how to enter data onto forms and do their genealogical research. Also once the initial technical work is done, the system can largely run itself without the need for additional technical expertise. But of course that collaboration is not inherently integrated with TMG and it is necessary to import GEDCOM of data from phpGedView and export data from TMG into phpGedView. As such I can see the immediate usefulness of an application that can synchronize genealogical research between a large number of users without the fear that data from one user may become "out of synch" with the rest. By the way WhollyGenes licensing of TMG shouldn't be a problem because the license is for the use of the program not the data. As such you are free to use whatever external software to maintain the data without violating any licenses. What I am really trying to say that while this is a fantastic idea, I have a few objections to the concept: 1. There are already a number of well-established solutions available out there. 2. There are already websites that provide hosting services for projects like this. 3. TMG's exisiting user base may not be large enough to warrant the development og such a major feature. If you are looking for genealogical online collaboration software with NO technical expertise required from your side, there are numerous hosts that do that too: http://www.ourroots.info/ http://www.gedview.com/phpgedview.jsp http://www.yourbeginnings.com/ All these websites use phpGedView as the platform, but similar services exist for other software. Ken.

It sounds like you have already done a fair amount of research into it, but there are currently many ways of doing just this; my way involves a program called phpGedView which allows pretty much exactly what you are looking for in terms of functionality: it allows you to upload a GEDCOM, it allows you to add users and define individual access to each of your users, it allows a community of users to come together to collaborate and organize events and research efforts. The actual program is very easy to install and configure. On the downside, is requires you either to: 1. Install your own webserver with the necessary prerequisites (PHP, MySQL, able to handle expected traffic load), which is my choice. 2. Use a third party hosting service (many of these services specialize in phpGedView and do most the work for you for a nominal fee). Ken.

I know back in 2007 Microsoft announced the end of the line for Visual Fox Pro, so unless unicode appears in a service pack I doubt we will ever see it. To what extent this affects future TMG versions, I don't know, but if I understand it correctly Unicode support requires a change in database engine. http://msdn2.microsoft.com/en-us/vfoxpro/bb308952.aspx Ken.

I agree 100%. I have been pushing for storage of relative paths instead of absolute for years now. I am using a system like you with one folder for every individual with exhibits and also one folder for every source with exhibits. I also have a separate folder for all images associated with places (such as maps, photos of houses, etc). It works good for me now because it is well organized and I have not yet had to change locations for all these exhibits. I had a similar problem when I moved from v5 to v6. Fortunately I had Visual FoxPro on my office computer at the time and was able to use that program's search and replace function to change all the absolute paths in the datafiles. It worked like a charm, but I didn't have as many exhibits then as I do now. Why the reluctant to rely on relative path storage in the datafiles is a question I feel remains unanswered. However, AS LONG AS you do not change drive letter and store the files in the same folder structure you're good to go. Ken.

I can confirm that I am experiencing many of the same problems. If the pictures are large enough (zoomed in) so that scrolling is necessary all kinds of problems arise (seems to mostly be with redrawing and repositioning the image on the window canvas). I haven't really found it too annoying yet because once I attach exhibits to persons I have an external program for viewing and highligting if necessary. But the few times I have; I have experienced the same problems John talks about. Ken.

I have posted a screenshot from TMG v6 that I feel illustrates what makes TMG so powerful. It allows you to start (if you so please) with a COMPLETELY clean canvas and build your own interface from that using the predefined screens and interface objects. What can be better than that? Sure you don't have the "pretty" XP/Vista/Web 2.0 feel of TMG 2008, but that becomes so unimportant when you realize the powerful functionality that lies behind and the fact that you can tailor your genealogical experience EXACTLY to your needs. As a sidenote, in about.com's regular genealogical review, FTM 2008 scored 2.5 stars, the lowest score of all the other genealogy programs, with TMG and RootsMagic on top. That proves that when it comes down to it, end-users appreciate functionality over "prettyness". Incidentially, the only reason RootsMagic got a higher score was because it was considered more "user friendly". And I think no one has the illusion in here that TMG is an easy program to use; it requires a fair bit of trial and error and reading and forum visits to get this thing going, but I can promise you that once it get's going; it wont disappoint you. Ken. Well, that attachment didn't upload for whatever reason, but it basically shows TMG with all windows and all toolbars taken away basically giving just a clean canvas with just the titlebar, menubar and status bar.

Honestly, in my opinion, functionality is more important than a "pretty" interface. To me it is better to have a Fiat with a Ferrari engine than a Ferrari with a Fiat engine... In terms of functionality TMG outperforms most of the competition by leaps and bounds (though I admit a few are beginning to catch up). So bottom line: Beautiful? No. Powerful? Yes. Ken.

I also use subfolders for storing exhibits, and I can confirm that Helmut's method works. As long as you do not restore the exhibits, the paths are left intact and will be accessible the same way from TMG7 that they were in TMG6. I am still waiting, though, for the day when exhibits will be stored in the database using relative paths rather than absolute paths. It will make migrating a project to a different computer or harddrive vastly more easier for those of us who find it necessary to split exhibits into multiple folders. But for now we need to make the best out of it and for that Helmut's way certainly works. Ken.

I have TMG installed on a different harddrive too (under Windows XP), with the data relocated to yet another harddrive. Hey, I even use Linux, and it works. One must also keep in mind: for the vast majority of TMG users the default setup works fine. Then, for the few users like us who for whatever reason find it necessary to tailor the program's presence on our system, I find it unreasonable for us to complain. Especially when, with some effort, it is possible to configure it pretty much exactly the way you want. I consider myself an advanced user now, and I spent a couple of hours getting TMG v7 to work exactly like I want it to with my multiple harddrive, multiple operating system setup. I am convinced that with some effort you'll get it to work too. And I am absolutely certain that more experienced users will step up and help you along. That's what the trial version is for; help us decide if the program lives up to our expectations before we buy. Ken.

I second this request. The "Add source" option (at least for me) is only used rarely and if you really like the reminders you have the option of having them popping up automatically. It's purely cosmetic and a few extra taps on the tab is no big deal, but I feel like excluding "add source" and "reminder" from the tab-order adds to the speed of inputing for those of us who like to use the keyboard as much as possible. Ken.