Helmut Leininger

Hi Raysmi, it seems to be a bit strange. I tried the followoing, which should be similar to your problem: I have a project with German place and name styles. I opened the dataset management to create a new dataset, the defaults of the styles at the bottom of this screen said German place and name style. I created the new dataset called test. --> it showed US name and place style. After changing these to German styles I closed the dataset management. Adding a new person to the new dataset gives me my German styles as default. Maybe you did not change the proposed value (you would assume that the same defaults as you have for the "standard" dataset are used).

I am sure this is a code set problem. TMG does not support Unicode/UTF, which is used by most programs in windows today (such as office programs etc.). As I said before, try editing it in TMG directly, e.g. replace the "of½her" by retyping "of her".

Could it be a code problem (Unicode, ..) ? Are you sure that there is a "normal" space character where the ½ is shown? Try to edit this memo directly in TMG to replace this character.

greg, 4. Based on Helmut's suggestion about disk file indexers, I'll also try to turn off Windows indexing (if I can figure out how). you may select the directories to be indexed in System Control (in German Systemsteuerung) / indexing options 5. I'm not sure about his suggestion to exclude the temp directory - "exclude" it from what? How do I get to the command line to "set tmp"? I mean do not index this direcory (with its subdirectories) and/or - if you have a trashbin extension like "Undelete Recovery Bin" or similar which extends the features of the default trashbin - tell this extension not to save files in and beyond the temp directos for later recovery. You can see which is the temp directory by two ways: 1) open o comand window (Execute cmd.exe) and type set TMP and set TEMP Microsoft Windows [Version 6.3.9600] (c) 2013 Microsoft Corporation. Alle Rechte vorbehalten. C:\Users\hl>set TMP TMP=D:\tmp\hltemp C:\Users\hl>set TEMP TEMP=D:\tmp\hltemp C:\Users\hl> 2) System Control / System / extended system configuration (or properties) / Extended / Environment variables

Greg, I have encountered this problem several times with - disk file indexers, like copernic etc. - trash bin extensions / replacements TMG creates and nearly immediately deletes a lot of temporary files during GEDCOM export. You should exclude the temp directory of the system (can be seen by set TMP and set TEMP from the command line) from such utilities.

Ok, it is clearer now. I thought that procedureal calls would mean traditional READ, WRITE, ... statements of "normal" files. That is clarified now. You are introducing a layer between the application and the database to have the same programming interface from the application whatever database is beyond. In my opinion, a good idea (it is relatively easy to exchange the database without influencing the application) when you do not use the "proprietory" DB SQL-extensions that every DB has (I don't think that TMG would have a need to do so). But does it really make it less vulnerable to SQL injection attacks (although I don't think this being a big danger for TMG, and aslo non-SQL data may be attacked)?

elevator wrote: Which ones? Do they really use "procedural calls" or just hide SQL ? What is your definition of a "procedural call? Then it is SQL. This contradicts what you said before: However, this applies much less to local databases. RobinL wrote: I think this is a multi-part issue. There are several databases out there that might be used without costs or with low cost only. But migrating the data from VFP to another database is the easiest part, is quite simple and could be done within a few days. The problem is the application using the database (i.e. TMG itself). VFP includes also a development environment with powerful tools and a programming language. This must be replaced and this implies that most of the code has to be rewritten ...

Only two remarks: 1) the mostly used databases today offer just an SQL interface, no "traditional" access 2) SQL-statements can be quite powerful and flexible and therefor reduce the programming effort (which also means costs) and testing of procedural calls quite al lot. It allows the programmer concentrate on the deployment of data, not their storage and retrieval.

I created a new tag, based on burial.

Hi Jak, I have been working in IT for nearly 40 years, from old punched-card based systems to Unix (AIX) systems, supporting a lot of migrations, databases, building of High-Availabiity systems. I agree with most of your statements, only a few comments from my point of view. I am not sure, if VFP can use multi-processors, although I have never seen TMG using more than 25% CPU on 4 4-processor machine. However, using more than one processor (at the same time) can only be done if several threads (tasks, works) can be run in parallel, i.e. are partially "independent" from each other and do not need the result from its companion. I have not investigated, if this would be possible in TMG. Microsoft describes VFP as an SQL-capable database. I do not know, if TMG uses the SQL-interface or a "classic" interface. Anyway, SQL itself does not give performance. It is "just" a standardised grammar for accessing relational databases and reduces the programming effort in the application. The performance increase (if any) comes from the database management - and most recent databases use large buffers to avoid disk accesses and have optimizers for recurring SELECT expressions.

Hi, As long as TMG stays based on Visual Foxpro, the Unicode problem cannot be solved. When TMG is migrated to another database, Unicode will come in "automatically" because I don't know an up-to-date database now that does not support Unicode.

I am doing more or less the same. I Use TMG for my researches. From time to time I export a part of the information to GEDCOM und import it into webtrees for publishing (only).

Demands are different. I definitely do not want my data stored somewhere in the cloud out of my control, subject to any possible hack and misuse. I like my data stored locally - and a possibility to publish extracts.

Automatic Relation Tag seems to work generally, but it does not if the relations are "too far away". At least This is my experience.

Michael, the location for the custom toolbar in TMG V9 is C:\Users\username\AppData\Roaming\The Master Genealogist v9. You may copy it to this location, but you will probably need to modify it to take care about the maybe new location of the used icons etc.

I don't have this problem. The additional lines show when the mouse moves over the text (content) of the tag (not when over the date or type).

Max, Also the buttons in the standard toolbar (tooltip text "Vorschau: Personenblatt - Erzählender Bericht" and "Vorschau: Personenblatt - Erzählender Bericht mit Quellen") work for me.

Hi Max, I just tried these reports from the dropdown menu with 2 different persons in my database - no problem. Then, I created the buttons in the custom toolbar abd retried again - no problem.

John, If you were not satisfied with V8, you probably won't find many new things in V9 (which is very close to V8). It depends on your preferred method of working. You might have a look at the Change log at the top of this forum. On the other hand, playing a bit with the trial version is not a big effort. But you should pay attention to the fact that V8 and V9 internal file structure is not backwards compatible with V7 - so you should try only with a copy.

Marlene, you should exclude the temporary directory (%TEMP%) from indexing trashbin programs.

Marlene, there is another interfering program on your computer. It will not be easy to find out. It might be some programs replacing the standard Windows trashbin, file content indexers, cloud synchronizing etc. There are several threads in the TMG V8 forum dealing with this problem.

I am experiencing the same problem (sometimes). It does not appear with TMV V8.08 using the same database

Jak, although being a TMG user since V6 and being fond of its power and its features, I definitely share your frustration about UNICODE. My main language is German (as well as most names), but as I am Viennese, I have a large number of Czech ancestors and names in my database. Many of them would have national Czech characters in their names and they cannot be well translated into "standard" characters. Not to speak about my wife's ancestors from Latvia, where they used the Russian alphabet during a long time. I have already considered to move to another program because of the UNICODE problem, but unfortunately, I did not find a program speaking German and having the features that I am used to in TMG. And a migration to another program is quite costly in terms of time and maybe loosing information for larger projects. I hope TMG is already working on this complex, but they don't give away any information, not to speak of a commitment. And there will be a point in time when I will be at the end of my tether.

Jan, Sorry about my mistake. The code is not in this mail, it will be only in the "Serial number .." sent by Whollygenes Support to the same mail address. Maybe you should check your Spam folder for a false positive.

Jan, the Serail number for V9 is different from the Serial number ov V8. You should have got it on Mails "Your Wholly Genes Order #...." and "Serial Numberfor The Master Genalogist v9 ...". it is *not* in the Receipt/Purchase confirmation. During purchasing the update in Internet one of the last forms should have shown the old and the new serial number in the left lower corner of the form. When unlocking take care that Name and Email must also match the data supplied during the purchase.