Hi Terry.

Sorry for the delay in my reply -- been heads-down coding for several days now.

>First off, I have performance worries. Our main database has 73 tables, 222 views, 67 relations, 3127 fields, and 225 indexes. To initially create the SDT metadata and to Validate the metadata takes about 7 minutes (that seems reasonable to me). But what is a bit unreasonable is the time it takes to simply open the SDT Database Explorer -- 5 MINUTES!

That's a pretty good sized database -- a lot of objects have to get added to the TreeView control. Also, while these objects are added, SDT checks each one to ensure that it's already been validated (has a record in the meta data tables). However, that said, I'm working on a new version that looks like it'll load *way* faster than the current version does.

>Every time I need to make a change to an index, view, or table I need to wait 5 minutes?

No. Although it may not be obvious, you don't have to use the SDT Database Explorer if you don't want to. You can continue to make your changes using the VFP Table and View Designers, then update the meta data using code similar to the following:

oMeta = newobject('DBCXMgr', 'DBCXMgr', '', .F., '[meta data directory]')
oMeta.SetDatabase('[your DBC]')
oMeta.Validate('[table name]', 'Table') && validate a single table
oMeta.Validate('[view name]', 'View') && validate a single view
oMeta.Validate() && validate the entire database

This way, you can still take advantage of the runtime functionality SDT provides (reindex, update, repair) without the overhead of the development time tool.

>Next, I am not sure I like the idea of having ten more metadata files to slosh around with the DBC.

Unfortuately, there's no way around this. The DBC just doesn't have enough information to be able to recreate corrupted indexes or update table structures. Yes, you can hard-code that information in a PRG or class, but then you're simply transferring the meta data to code, which is *way* more difficult and error-prone to maintain.

>Plus, we have a total of 5 database containers in our application (one foundation container and 4 sub-module containers), so we are talking about an overhead of 50 more files to make the SDT usable.

Nope. SDT's meta data tables can include information for multiple DBCs. The manual describes how to do this. That way, you have all the meta data for your entire app in one place.

>REINDEXING: I could write a reindexer that just uses the basic DBC and table structures.

"Basic" would be the operative word. It took me 80 hours to write the Reindex methods alone. The reason is because things are way more complex than they used to be in 2.6. For example, you may not be aware of this, but if the index of a table with a primary key is missing or damaged, VFP won't let you open the table anymore! The only solution is to use VALIDATE DATABASE RECOVER, choose "Remove" from the resulting dialog, and then recreate the indexes. Of course, you can't use this from anywhere but the Command window (not even a PRG in a development copy of VFP), so that makes it next-to-impossible at a client site. And that's just *one* of the gotchas!

>UPDATES: I like this a lot. Being able to slap a new DBC and metadata files in and just to an Update() to get the whole database in sync sounds great. But we have been doing that sort of stuff procedurally for so long now that we don't have a huge issue with it any more.

Procedurally works just fine, but again can be a lot of work to maintain and testing is more difficult (you can't run the update routine twice, for example, without restoring the former structures first)

Don't give up on SDT just because the SDT Database Explorer is slow for you. I think you'll find that you can still take advantage of SDT's runtime capabilities with very little effort.

Doug