Jump to content

jak

Members
  • Content count

    7
  • Joined

  • Last visited

Everything posted by jak

  1. I'm running TMG 8.08 US on Windows 10. While re-indexing my project database, Windows crashed. Upon restart, in TMG I got repeated errors when trying to open my main project. Eventually, when restarting TMG, it said it was in repair mode. I was able to successfully open the sample project, but when I try to open my main project, it starts creating indexes, I still get many errors, I click ignore many times, TMG wants to open a dbf file, and eventually it tells me the project is in use elsewhere. I believe my project data is intact, but something is corrupt. Can you help? Thank you, Jim
  2. Project Corrupted

    Thanks to Jim Byram for his knowledge, his kindness and his willingness to help. Through his work, I've recovered my project and learned a valuable lesson about frequent backups. Thank you, Jim
  3. I have been waiting since V7 for TMG to move from the long obsolete Visual FoxPro environment to a modern programming environment that fully supports multiprocessing CPUs, large RAM and UNICODE. I was devastated when V8 was released, again based on obsolete software technology. A number of users pointed out the need for TMG to be rewritten in order to support the improved hardware/software environment. This was met by stony silence from Wholly Genes. Now, V9 is announced with the comment "After eight free upgrades in v8, there is a charge for this upgrade." While I have no problem in principle with supporting Wholly Genes and paying for a new version, let me humbly point out that a new version should not be defined by how many free updates to the previous version have been released. A new version implies significant new functionality. I my view, V9 should have been called v8.09, since the long hoped for rewrite and upgrade are still nowhere in sight. I use a high end laptop with current generation multi-core CPU and 16 GB RAM. TMG uses little of this. I might as well be running on an IBM PC/XT. Re-indexing my large database takes 9.5 minutes. The process uses 12.5% of 1 of 8 available cores and only 309.5 MB of the available 16 GB RAM. In addition, TMG9 still does not fully support UNICODE (for non-Western alphabets) and will never support it as long as it is Visual FoxPro based. Also, TMG has never included a high quality export function, allowing data to be exported to a neutral environment. I really can't put into words how frustrated and disappointed I am with Wholly Genes and TMG. TMG should have migrated to a modern software environment several years ago. Will it EVER happen? I'm doubtful. I like TMG quite a bit and would like to see it improve. Based on V9, I'm very depressed and discouraged.
  4. Thanks to those who have replied. We've gotten off into the weeds a bit on technical hardware/software issues of no interest to genealogists. Below is an additional 2 cents worth. Non-Western Alphabet Support for Names and Places The most critical deficiency of TMG I can see is lack of support for non-Western alphabets. To me this means UNICODE. I'm sure Wholly Genes are well aware of this and would dearly love to include UNICODE support. I believe the problem is the software environment - MS Visual FoxPro. According to Wikipedia (Comparison of Relational Database Management Systems) the last release of VFP was 2005 and the last update in 2007. Microsoft has been trying to kill it for many years and no longer supports it. In particular, VFP is incompatible with recent MS Windows software libraries and MS software environments like .NET. Virtually all current software environments include UNICODE support by default. So, the message is - migrate as soon as possible to a currently supported, full featured software environment, You will get UNICODE support automatically and be able to take advantage of the latest software tools - multi-processor, multi-threading, access to large memory models, latest software libraries for graphical interface, database access, latest most highly optimized code libraries, etc. Database Engine Yes, strictly speaking, Structured Query Language (SQL) originally referred to a query language only. However, it had implications for the underlying database engine. Today, in my mind anyway, SQL implies both the query language and the underlying database engine. Microsoft's most powerful and capable product is called MS SQL Server. Presumably, the underlying engine is some sort of relational database. The point is that MS SQL Server (various versions) is far more capable and powerful than VFP. No serious application would use VFP today in preference to MS SQL Server. All of Microsoft's development effort is targeted for SQL. It supports large databases, parallelism (multi-threading), multi-processors and it has been and continues to be optimized in various ways for maximum power and speed, as well as for rapid development. There are alternatives like Oracle, Postgres, and others, but I would stick with Microsoft which offers a rich software environment for development. A currently supported full featured database (whichever you choose) will blow the doors off VFP). Data Interchange I certainly agree that an interchange format is not just a Wholly Genes issue. But let me point out that GEDCOM was developed largely or entirely by the LDS church. The lack of a more powerful and capable GEDCOM replacement afflicts every genealogy program and company in the market. This does not let Wholly Genes off the hook. A modern replacement for GEDCOM is urgently needed. Every genealogical software company that claims to be a leader in the market is a prime candidate for development of the replacement. If you are a market leader - develop and implement a viable GEDCOM replacement. There are a number of aborted XML based solutions out there. No one has stepped up as the LDS church did to solve this problem. The longer this problem festers, the harder it will be. My goal here is just to encourage Wholly Genes to face the inevitable now. Move to a modern, supported environment and the potential for product improvement is enormous.
  5. This topic has been around a while and has generated a variety of comments. I am a retired IT person whose knowledge is significantly out of date. I may be wrong in some of my comments and would be happy to be educated. That said, I think several of my original concerns still have some validity. 1. UNICODE No genealogy program can be a professional product without support for non-Western alphabets. This seems to mean UNICODE support. Virtually every serious genealogist eventually links to ancestors from some part of the world which uses alphabetic characters not supported by TMG. This is completely unacceptable and should be an URGENT priority for Wholly Genes. My impression is that the reason TMG does not support UNICODE is that it is based on MS Visual FoxPro, a long obsolete and no longer supported software environment. If this is correct, then UNICODE support would require a complete re-write of TMG using more modern software tools. I appreciate that this is a big job, but it is an issue that needs to be faced NOW. The use of Visual FoxPro has many more implications. I suspect that VFP does not support multi-processors and large memory models, meaning that TMG does not make use of modern PC hardware, leading to unacceptably slow performance in a number of areas. In addition, I suspect that the use of VFP means that TMG can not make use of current graphical interface features and must rely on older, less capable graphical features. 2. Database My impression is that TMG does not use the SQL database or something similar. This leads to poor performance and makes TMG increasingly obsolete. Again, there is a performance issue - especially with large databases. 3. Data Interchange TMG does not seem to offer high quality export of precious genealogical data to a neutral format for import into a competing product. To some extent, this appears to be a generic problem in genealogy and not solely a TMG problem. However, Wholly Genes should be at the forefront of developing and supporting a full featured neutral import/export format. This should be a priority for the entire genealogy community. 4. Cloud Support Several members have commented on the cloud. In my view, I don't want my data on the cloud, I want it on my local PC. The cloud has some obvious advantages, but I only use cloud solutions for non-personal info and would never trust a cloud solution for personal info. Security is a critical issue for cloud based solutions. The handwriting has been on the wall for several TMG versions that major changes are needed. It is the case that the above concerns have been raised previously on multiple occasions. I am not aware, however, that Wholly Genes has ever responded meaningfully to these concerns. I am a huge fan of TMG and would like to continue with it. It has many powerful features. In my view it is one of the best genealogy programs on the market. That said, users have been waiting a long, long time for some indication from Wholly Genes that they are determined to upgrade their product to take advantage of modern hardware and software. We just can't continue down the path to obsolescence forever! At some point, many of us will be forced to jump ship - however painful that might be.
  6. I use the Relation tag to track relationships. As I understand it, this tag is static, so I frequently fresh to update the relationships. With 110k plus individuals, refreshing the relation tag takes in excess of 15 minutes. I have a fairly recent PC with dual core CPU and 2 MB RAM. Questions: How much RAM will TMG 7.04 use? If I upgrade to 4 MB RAM, will that speed refresh/reindexing? Would you expect the index time to improve significantly? Can TMG use more than 4 MB - say 6 MB? TMG appears to use only 1 core. Is there any hope that TMG will be able to take advantage of mutiple cores in future? Finally, if I had one wish for TMG 8, it would certainly be to abandon Foxpro and move into the 21st century. It is inevitable. I hope you do it in the next release. So many advantages would flow from this decision. Thanks, JAK
  7. Relation Tag

    Ooops, of course I meant GB, not MB - off by a mere factor of 1000. I'll also revise the refresh estimate to in excess of 30 minutes, sigh. JAK
×