elevator

Yes, we're on the same page now, Helmut. Talking about attacks; I think pretty much any time information is put on a distributed system you have potential for attacks on this information. This may be going quite a bit off topic for this thread; but if we're talking about SQL injection attacks in particular, one major way to avoid it is by what Wikipedia calls "object-relational mapping" which keeps user input isolated from raw SQL calls. Injection attacks are, of course, only one way to compromise data in a database, but I assume other systems are vulnerable too; not only to injection attacks but also other attacks. On XQuery, for example, a simple Google search yielded many articles giving examples of not only injection type attacks, but many other types of attacks as well.

Of course if we use database systems like MySQL, Microsoft SQL Server, PostgreSQL, etc. then the interfacing with the database is necessarily done using SQL, but I think we're either talking past each other or misunderstanding what the other means by SQL calls compared to procedural calls. By procedural calls I mean the process of abstracting the database calls. In other words the application shouldn't be issuing SQL calls. The whole point of a third party library is to make procedural calls disassociated from the SQL syntax. This not only makes it easier to switch out database providers at will (as we see with the PEAR library in PHP, for example), but only makes it possible to sanitize any database call coming from the application. Sure, if you use a database system which inherently uses the SQL language to extract data then at the basic level all calls will be SQL calls, but this is misunderstanding how the system works. The whole point of "procedural calls" is to create an abstraction layer that could care less about the underlying technology. Does that clarify what I mean? As a point of comparison look, for example, at the GRAMPS project database, which currently uses Berkeley DB (in the past it was just XML). No. As I said above; abstraction and encapsulation are two different things. Abstraction makes different database technologies look like the same technology to the consuming application; encasulation does not. No it does not once you appreciate the difference. Operating systems are perfect examples. You can support hundreds of different types of hardware without the user application having to worry one bit about the underlying hardware technology. It is all dealt with by libraries further down the chain which creates layers of abstraction; essentially making every piece of hardware look identical to the consumer application. Imagine the headache if consumer applications had to implement raw hardware calls to every piece of hardware they wanted to support. Of course I am putting things a little on the edge here, but I hope you appreciate the difference. Of course, but cloud-based environments were one of the topics up for discussion. And I thought I made that quite clear in my post. Distributed databases are by definition more at risk than local databases are.

I disagree Helmut; especially on your second point. So lets do the second point first; many database engines come with the procedural calls already developed. In fact if you were looking to "reduce the programming effort", as you say, it would be madness to develop a database engine from scratch in-house. Rather a third-party engine is used. Most such third-party solutions come with various ways of interfacing with database connections; be this SQL statements or procedural calls. Distributed applications (such as cloud environments) would benefit far more from a more secure approach than a desktop environment. This is common practice in the development world today; graphical engines are developed and used over a wide range of applications/games, same goes for audio libraries, physics libraries, etc., etc. Not only does such an approach dictate rapid application development but it also benefits from the testing already done on the existing framework. On your first point; I'd say it is a mix. PHP for example, which is used for many web-applications, take a dual approach. They encapsulate the SQL calls in procedural calls so that the statements can be sanitized and evaluated for grammatical errors and injecton-type attacks. The way in which the calls are made internally I think is largely irrelevant. The average user aren't going to care squat about how the data is extracted or otherwise manipluated. The only time it would matter is for third-party addon support and such.

I am wholeheartedly with you on the Unicode and the need get away from the VFP platform. However I disagree with point 3 and partly point 2; and here's why: the limitations on data interchange lies primarily with the GEDCOM standard, not with TMG. WhollyGenes is actually one of the few companies who (at least in the past) have published the database schema. Is this ideal? No. But the data composing family relationships and history can become quite complex and every software developer creates database schema's that fit their visions for the software. The problem is; unless each developer specifically implements import functions for competing database schemas, we're left with GEDCOM as the only data interchange standard for genealogical data. We cannot blame WhollyGenes or any other software developer for storing their data in different ways, and we cannot blame them for not imcluding import functions for every competing developer. Certainly, making the database 100% GEDCOM compatible would leave the database unable to deal with the complexities of modern genealogical databases. Regarding point 2: this is a rather vague criticism. SQL isn't really a database system but rather a way to maniplulate data within a database. Most genealogy software today use some sort of proprietary format or they use a third party database engine. This engine may or may not be interfaced using SQL. In fact database engines may work in different ways; they may allow the user to issue direct SQL calls to the engine and get a dataset in return, or there may be preprogrammed procedural calls which when called from code accomplishes the same thing. And depending on what you mean by "SQL database", I would even say it could even be a security issue. Better in my view to abstract database calls into well-tested prcedural calls rather than exposing the database to standard SQL queries. One of the most serious security issues with web-based databases today are SQL injection attacks. But like I said before; I largely agree with you: TMG must depart from the outdated VFP platform if it is to survive and with that departure UNICODE support will automatically follow. I just hope that despite the eerie silence from WhollyGenes such a rewrite is already on the drawing board.

These threads have indeed come up many times, but I certainly don't feel as though WhollyGenes have addressed the concerns; and I lurk both here and on the mailing list. We all know that TMG is built upon a dying platform and that a rewrite would, at some point, be necessary for this wonderful program to continue to compete with what's out there. I also think that most of us understand the cost associated with such an undertaking. Because of the work and cost involved I understand that a release for such an upgrade couldn't be promised; but personally I am not asking for that. All I want to know is that resources are being allocated to start this process. And as I said in a previous post; I'd be most willing to buy future upgrades (including this version 9) if I knew that resources from that sale would be allocated to move the database to a modern platform. As for Unicode, there are many other genealogy programs that do not support it, but it is indeed a shrinking crowd. My concern is that as long as the very foundation upon which the program is built is outdated, fixing the Unicode problem will forever remain impossible. Bottom line is; WhollyGenes could announce a long time goal of a platform update to ease the concerns of its user base without having to commit to an actual release date. In fact; this is the way they've been doing it all along. They have always been incredibly hesistant to reveal any information about their dedication to the development of the program. Updates appear sporadically and almost entirely without warning. No wonder long term users are worried about the long term viability of this wonderful program. I wholehearedly share the views of the OP and some of the other posters here; TMG v9 was a disappointment. A minor upgrade without even as much as a pip about the future and the things that REALLY matter for the long term viability of the program. There is only one circumstance under which I will pay for mediocracy: if it comes with at least some roadmap for the future. In this case it is called an investment. Version 9 can, in my view, be called nothing else but mediocre. So if I am to "invest" in it I have no problem doing so if it comes with some indication that change is on the horizon.

I agree; I do not like my data in a cloud-based environment either, but I recognize the value of it. Right now my system consists of a centralized Linux LAMP server running webtrees on which I have a basic and very abridged version of my research. I use this data to collaborate with other researchers and interested family members. Any changes made by outsiders are then synchronized with my original database after being sourced. For this reason a version of TMG that support a cloud-based database has never been important to me. I like to be able to personally guarantee the veracity of the data that ends up in my database and therefore having an external database completely isolated from my original TMG database works for me and has proven incredibly useful when collaborating with others. That said; I do like TMG for what I am currently using it for. I just don't think version 9 adds much over version 8; and certainly none of the platform issues I think many users were hoping for: maybe not a complete fix, but at least some indication that it is on the horizon.

I am also a long time TMG user and I too find myself rather disappointed. Unlike some commenters here though, I really liked version 8 and think it was worth the upgrade, but I admit I had hoped for greater things for version 9. It definitely has the "feel" of a minor upgrade rather than a major one and after careful consideration I have also come to the conclusion that it is simply not worth the money. I have no problem paying for these upgrades if there was some sign from WhollyGenes that resources are being put into migrating the program away from the outdated technology on which it is currently based. UNICODE didn't really use to be an issue for me, but in an increasinly international world it is slowly becoming absolutely essential. So while TMG continues to be a fantastic program, the lack of reassuring communication from WhollyGenes that resources are being directed towards a fundamental update of the underlying database engine prompts me to simply stick with version 8 for now. If, meanwhile, the need for unicode becomes too great to continue to ignore I'll consider switching software at that point. But I am cautiously optimistic that a proper update will be announced before that...

I guess it depends on how we all use the citation. The "empty space" is, as Virginia says, the space allocated for the citation detail column. I use citation detail quite a lot (page number and reference numbers, for example) and so in my case the current behavior is exactly how I want it. But considering how good TMG is about allowing the user to customize every other aspect of the layout, it seems reasonable to be able to control the size of these column as well.

I have used the Exodus project by norwegian Leif Biberg Kristensen. He migrated from a TMG database to a self-authored solution. It was the precursor for his Yggdrasil project. Both of these are available with full source code on his website. You can read about it here: http://solumslekt.org/forays/tmg.php It does require quite a bit of knowledge of php and Postgres or MySQL. You can read about Yggdrasil here: http://code.google.com/p/yggdrasil-genealogy/

After installing TMG 8 I have been having error with the properties screen of items in the Exhibit log. I used to right click on the exhibit and choose Properties, and edit the properties that way. But now whenever I try to access the exhibit item properties I get the following message: Function argument value, type, or count is invalid. 43 CUSSHORTCUTMANAGER.SHOWMENU My options are Abort, Retry or Ignore. Abort seems to simply close the properties dialog without any side-effects, but Ignore opens a bunch of error messages making the only realistic option to force end the program. It seems to have no adverse effect on the exhibits or data in the exhibit log. So, now I am forced to use the "Properties" button in the Exhibit Log dialog rather than right-clicking the exhibit as I was used to. Is this is known bug, is it reproduceable, or is it just me? Thanks, Ken.

Ok, I tried it again and it worked. I have no idea what I did before.

Thanks alot Jim. I'll have to try it again then, last time I tried it the yellow on grey disappeared completely once I enabled tag label colors (the column was the original black text on white background) and the tag appeared in the specified color. But if I can get mine to look like your screenshot above that would be fantastic. Thanks again for your help.

I had been looking forward to the new Tag Label Colors in TMG v8 (and I do like the feature), however after working for a while I have at least one concern. Whenever someone is added to a tag as a witness, a witness tag appears in the details window of this witness. By default (and without tag label colors enabled) this witness tag is colored grey with yellow text. I like this because it quickly lets me isolate those tags in which the person isn't a primary, but rather simply a witness to an event. However, as soon as I enable Tag Label colors this default witness coloring disappears and it instead takes the colors of the tag that the witness is associated with. This seems inconsistent to me because the witness isn't itself a primary in the event that the tag describes. I would instead like the witnesses to preserve the grey with yellow text color, while the primary (or primaries) gets the defined tag label color. I though perhaps it was possible to specify a different tag label color for witnessed events, however this seems not to be possible. But just to make sure, my question is: is it possible to enable Tag Label Colors while either preserving or defining a separate tag label color for witnesses? Thanks, Ken.

As a side note; I use Linux (Fedora) quite a bit as well and TMG runs quite well (with a few hiccups) under Wine. This, of course, is not "OS independent" but rather the introduction of the necessary OS features/libraries to make a native Windows program run on Linux. In any event, if you use Linux you can, with some effort, make it work -- still without unicode support though!

FoxPro, as far as I know, doesn't support unicode natively, so any plans for true unicode support may require a departure from the FoxPro platform. I have read, however, that there are workarounds to allow the use of unicode within FoxPro. In any event, the end-of-the line for FoxPro in 2007 (and the end of the support cycle in 2015) calls into question the long-term viability of any program that insists to remain on the foxpro platform.