Hi Doug, than ks for the reply. I'll try to explain my self better in some points:

>>- Improvement in dealing with scenarios in which there are several folders with a different database in it. Sometimes you have to be very careful when initializing DBCX manager and SET("PATH"), becasue you could end up using another COREMETA than the intended one. This situations are very difficult to trace and debug and very time consuming. SDT should be more "clear" in these complicated scenarios.
>
>I'm not sure I understand this issue. One of the parameters you can pass to the Init method of DBCXMgr is the path for the meta data tables. If you neglect to pass that, you are relying on VFP to locate the tables for you (the current directory or PATH setting), which doesn't seem like a good idea to me.

As far as I remember (I did not document this, nor did I report to you, it's my fault), the problem was that if I want to open a certain DBCX in a given lcPath, if there is another DBCX in the set('path'), the DBCX object instantiation takes the DBCX in the set('path') instead of the one that I want to open, even if I put the lcPath explicit in the init call.
I did have some difficulties working with several DBCX objects in which every one had it's own and different metaData.

>>- When the user defines it own fields in the standard database, one has to redefine views in the application. These function, redefineViews(), is outside the SDT class, and I have to tweak the files in every new version of SDT. This functionality (adding fields to the database inside the application) is a common scenario.
>
>I'm not sure I understand this one either. RedefineViews is provided in a different class for several reasons, one of which being that it's really a design-time behavior while SDTMgr provides mostly run-time features. If you need that behavior at run-time, simply include the class in your project. What tweak do you have to do when a new version of SDT is released?

You are right, one can distribute this VCX. It was a suggestion because I don't like to see my EXE's growing, so I like to include the least the better. RedefineViews is need at runtime when you let the user add new fields to the database, that's why I tweak SDT to include it.

My application is a heavy user of SDT, it exploits almost every capability SDT offers. The user can handle many companies, and each company has it's own MetaData definition (the user can add custom fields to each company). When we upgrade the application, we have built an update routine based on SDT that updates common structure of each company, and then adds the custom fields. Everything is done automatically, we do not have to do onsite upgrades.
In custom fields and common fields, the data dictionary is heavily used, and user interface, validation, reports, labels, ... rely on it. This is why I have come across very complete scenarios, and what I missed the most are tools to take better advantage of the data dictionary.

All in all, as I told you SDT for me is a must for any VFP developer. Thanks again for developing it,
Javier.