Hi Doug,

I use your SDT and I think is a great product, one I would recommend to every VFP developer. Nevertheles there is no software product that cannot be improved, nor is SDT. Maybe is our fault (your customers) who have not given you suggestions or good feedback, but along these 2 years that I have been using SDT I have come across with several improvements that I thought would be nice to implement. I don't remember every suggestion, but I can tell you 2 or 3:

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

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

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

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

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

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

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

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

Just my two cents.

>
>While SDT continues to be an essential tool for a lot of VFP developers, it's a mature product, having been released more than 10 years ago. I honestly can't think of any other important features to add to it, so realistically, it's in maintenance mode too.
>
>We don't have plans to integrate SDT with SQL Server or Access. There are several tools available that do what SDT does for SQL Server; not sure about Access.
>
>Doug