Jump to content


Senior Members
  • Content count

  • Joined

  • Last visited

Everything posted by elevator

  1. TMG9 a Huge Disappointment

    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.
  2. TMG9 a Huge Disappointment

    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.
  3. TMG9 a Huge Disappointment

    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.
  4. TMG9 a Huge Disappointment

    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.
  5. TMG9 a Huge Disappointment

    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.
  6. TMG9 a Huge Disappointment

    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.
  7. TMG9 a Huge Disappointment

    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...
  8. 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.
  9. 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.
  10. Direct database access

    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/
  11. 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.
  12. Tag Label Colors and Witnessed Events

    Ok, I tried it again and it worked. I have no idea what I did before.
  13. Tag Label Colors and Witnessed Events

    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.
  14. TMG v.8 is here! At Charleston NGS

    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!
  15. TMG v.8 is here! At Charleston NGS

    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.
  16. TMG v.8 is here! At Charleston NGS

    Let's hope not! Unfortunately, if WG have any plans of moving away from the FoxPro platform with v9 I fear that they may need at least that amount of time... so you might be right.
  17. TMG v.8 is here! At Charleston NGS

    I love the oh-so subtle use of sarcasm. In any event; seeing that TMG is, as you say, possibly unique in offering an accent color feature, any amount of conditions are superior to the competition. There seems, to me, to be more important issues to press - such as the future of TMG on the FoxPro platform. I will definitely upgrade to TMG v8 and I am very excited about the final release, but I am (and obviously not alone) concerned about the future of the program. Genealogy is a long-term hobby, and it is vitally important for me to be confident in the future viability of the software solution I use. I also need to know that the company behind it is open to assure the community of its continued efforts to maintain TMG as best choice out there. Lets see what the reviewers think of v8 when the release is final and how they feel it compares to the rest of the crowd. Ken.
  18. The Future for TMG

    It is indeed true that the community has been quite vibrant here over the last few years, especially since the release of version 6 and 7. But it certainly seems to have decreased the further we get away from the last update. And the general disgruntlement also seems to increase as news of version 8 remain maddeningly absent. In that case we can only hope that the new release will calm some of the concerns users have expressed here. Especially those concerns related to the future of the program. The worst thing that can happen to a software solution is if its users start to doubt its future viability. And an absent or inactive developer often tends to support those doubts.
  19. The Future for TMG

    Obviously there must be a trend here though. Unless WhollyGenes is posting official notices, chat transcripts and newsletters to the TMG mailing list instead of here; it is clear that company feedback to its users have decreased. At the same time I have noticed a greater level of concern amongst TMG users regarding the future of the program (such as the perceived company inactivity, the lack of a regular regular release schedule, and development platform). Don't get me wrong though; even now, without any updates in over two years, TMG is in my mind, without a doubt, the best genealogy program out there, so I really hope that the new version 8 will yet again reassure its users that TMG is the best program out there and intends to maintain that position for the future.
  20. The Future for TMG

    Isn't this the official forum?
  21. The Future for TMG

    I think its been pointed out before, but response and updates from WhollyGenes has slowed to almost non-existent. This is unfortunate considering how many people are apparently concerned about the future of this fantastic program. The previously vibrant community has slowed to a murmur. For example, take the newsletters and chat transcripts. In 2004 there were 14 newsletters, in 2005: 18, 2006: 19, 2007: 20, 2008: 18, 2009: 11, 2010: 5 and none so far in 2011. Same for chat transcripts; steady decline. 2007: 8, 2008: 9, 2009: 6, 2010: 2 and none in 2011. This doesn't mean, of course, that the developers aren't busy cranking out another great release backstage, but it does look to me like the community surrounding the program is shrinking and that user-confidence is on a steady decline.
  22. Sureties in Tricky Conditions

    I disagree with Terry here. I think sureties is an important part of citing sources for your data. I know of several professional genealogist who consider sureties absolutely essential. The most important part, of course, is first to cite at least one source for every piece of information in your data set. Secondly, it is important to convey how confident you were in those sources or the type of source you cited. I have seen the following five-level surety scheme used: - : data disproven 0 : guesswork 1 : low quality secondary source (for example a casual conversation with a family member) 2 : high quality secondary source (for example work of a professional genealogist or genealogy books written by professionals) 3 : low quality primary source (for example a digital transcription directly from a primary source) 4 : high quality primary source (the actual primary record in hand, preferably photographed and available for future consultation) TMG only allow for 4 surety levels, so I combine both low- and high quality primary sources into one category; "primary sources" that I give a surety of 3. It is true that sureties can to be somewhat subjective and arbitrary, but they can still portray vital information about how comfortable you are about the data in your data set. For example, it is especially important to note when a particular source has been disproven or when a particular set of data is the result of guesswork on your part. I know a lot of people remove sources that have been disproven from their project, but I think it is important to cite every source relevant to your project (disproven or not - especially when disproven sources are primary) and then indicate, using sureties, to what extent the data can be trusted. If we follow this scheme thit means that in a TMG project it is only sureties 1 and 2 that are subjective, sureties -, 0 and 3 all have well-defined rules for their use. --- Now back to your question regarding the name. I solve your problem in one of two ways. If the spelling of any part of the name is different from the name I have listed as primary, I make a new Name-Var tag and cite the source there (with sureties). If the name matches the spelling of a name already associated with the person, I cite the source with that name but make a note in the notes box of the particular source citation indicating that the source does not list a last name, or that the last name is known with lesser confidence than the first name. In regards to the second question; I would give that parent-child link a surety of 0, because it is just guesswork from your side. Unless you have an actual source to cite (except yourself), then it seems wrong to me to use any other surety level. Ken.
  23. I have always been somewhat of a Linux (Fedora) fanatic but have always come back to Windows for certain tasks (Genealogy being one) as Linux seemed to lack software able to compete with their Windows counterparts. After Sun came with its newer versions of OpenOffice and a myriad of other marvellous innovative programs were developed I have found myself booting into Windows less and less. I have on several occasions played with GRAMPS, a genealogy program I consider to be the absolute best on the Linux platform, but still thought it lacked the necessary features to compete with for example TMG. Recently though I had been experimenting with version 2.2 and just a few days ago version 3.0 came out and I must say that I am mighty impressed. The program has the same "free" feel as TMG, and a sourcing system I feel even surpasses that of TMG. The general speed and response of the program is also superior to any other program (but might be due to the OS). Admittedly, it is still lacking some of the more advanced reporting and charting features I like in TMG and the ability to properly register and document conflicting data, and also, like TMG, has sacrificed some of it's user friendliness in favor of a feature rich base. GRAMPS still sports features such as sources, repositories, roles, place list, etc. and the ability for third party plugins to be developed. It still lacks a bit in the multiuser department though. I personally am left, after playing with the program for a few days now, with the feeling that this is a program to watch out for. It is not far behind TMG as a serious genealogy program for the professional, and certainly, in my opinion, is the best choice for the Linux platform. Has anybody else used this program more so than me? I would love to hear input from people who have been using this program extensively and know what the goods and bads about it is compared to TMG? Thanks, Ken.
  24. Surety Problems

    I am not sure if this has been up before; but a simple search yielded no results so here goes: I am having a few problems with my sureties in TMG v7.03. I am revisiting a few people to cite some new sources that I have come upon. In the process of doing this I realize that the surety values for the citations already there are completely off. I am very meticulous about using surety values for every single citation I input, as I use these surety values alot in my research. What I have noticed is that the surety values that show on the "Details" screen for a particular person does not correspond to the surety values of the combined citations for a particular tag. I hope that make sense. Let me illustrate with an example: On my detail screen it can say for example: Type | Date | Name/Place | Age | 12DPM Birth | 25 Oct 1823 | Vestfold, Norway | 0 | 12.3. While in the citation box it may say Citation 1: 3.32. Citation 2: 1.1.. Citation 3: 1.11. I don't know what has happened, but what the Birth tag on the detail screen should say in the surety section is, of course: 3.32. It is easily fixed by simply opening the tag and pressing ok to re-save it. As far as I can see no citations are missing (which was my initial fear remembering the problems with version 6 and missing citations) Anyone have any idea of what might be going on and if there is a global fix for this? I have tried running the reindex, optimize and verify file integrity maintenance functions (in fact I run them all once a week when I back up my data), but the problem seems to be persistent, though as of yet only evident on people I have not edited for some time. Thanks, Ken.
  25. TMG - Linux

    It works fine with Fedora 12 and Wine. Here's a link to the AppDB entry for TMG 7.04: http://appdb.winehq.org/objectManager.php?...TestingId=23660 Ken.