Hi Javier.

Thanks for your suggestions. I'll address them one at a time.

>- 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.

>- 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?

>- Repairing corrupted files could support more corruption options. This is a never ending development task, as there are many. many different corruption sources. However now I have 3 different utilities to repair corruption problems, and it could be nice if SDT could handle more options.

It's something I considered at one time, but given that there are a number of great repair utilities available, such as FoxFix and Recover, I decided not to reinvent the wheel on this issue.

>- The interface to query the data dictionary could be improved. There is only one function to recover many records, DBCXGetAllObjects(), and more could added (or it's implementation could be more developer friendly). Querying the data dictionary is not very user friendly, and would be nice to have more tools to do so.

I agree with this one.

>- The help files could have more examples. This is a feature of any software, documentation, and no matter how good is the software it is useles is one cannot fully manage it.

Fair enough.

>- The "environment in" in general could be improved. Sometimes I have to set the database before calling funtions, sometimes not, which force me to make a lot of trial and error trying to remember whether a function did work setting the database before or not. SDT could be more independent from the "environment in", and pass the database as a parameter if needed (moreover taking into account that SDT works with it's own internal dataSession).

Most methods do allow you to pass the database as a parameter, albeit as a kind of ugly one (eg. Database!Table); we were following VFP syntax on that issue. However, you're right -- there could be more consistency, so all functions permit the database name to be passed.

>- The whole DBCX managers idea is a great one in paper, but I wonder how many people have developed managers (except for Doug Hennig and SDT manager, of course). Having the chance to have many managers adds a layer of complexity which is under exploited, in great part because it's not easy to develop a new one, again I think the interface is not the prettiest.

There are at least two other managers: one provided by F1 Technologies as part of Visual FoxExpress and one by Micro Mega as part of FoxFire. Given this, plus the fact that changing the design would require a nearly complete redesign of SDT means this one won't change.

>- Integrate a own View builder. I know there are some View builders around, but if you tell me you can't think of new features, this one is a nice-to-have no one would complaint about.

This one definitely won't happen: it would be a lot of work, and there's a great replacement view designer already available, View Editor Professional from White Light Computing, that is integrated with SDT. As with the repairing corruption issue above, I don't see the need to have one tool do absolutely everything for you; instead, having several "best of breed" tools that cooperate makes more sense to me.

Doug