Hey all,

We have just received our copy of Stonefield Database Toolkit, and I was initially excited to see how useful it would be in three main areas: Reindexing, Repair, and Updates. But upon a moderately involved run-through of the product and the manual, I fear that I am either missing something, or this product doesn't quite fit with our established standards (though as a generic tool I think its wonderful).

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! Every time I need to make a change to an index, view, or table I need to wait 5 minutes? (My machine is a P166 with 64 MB of RAM). To make matters more complex, I am only one of 4 developers who are making lots of database changes every week. I don't like the idea of having to validate the metadata all the time (since they will have to use standard modification tools -- we only have one copy of SDT). We could get more copies, but that would make a $300 investment balloon to over $1000. I know that is still not much, but it is more than we were anticipating. Am I missing a trick to opening the Database Explorer more quickly? Or can the Database Explorer be open for one table or view at a time to make it quicker? I did not see mention of any such capability in the manual...

Next, I am not sure I like the idea of having ten more metadata files to slosh around with the DBC. We already have trouble keeping our DBC together, so I worry that having more metadata files could make things even worse. 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. Does anyone have any input on using SDT in a fairly large, complex application?

Basically I guess I see SDT's metadata as overkill for the things we need it for:

REINDEXING: I could write a reindexer that just uses the basic DBC and table structures. Sure, relations and such are tricky, but I have gotten pretty intimate with the DBC over the last year, and am pretty sure I could whack out a reindexer in a day or so. It could be as generic as the SDT reindexer and would require no additional metadata overhead.
RECOVERING: We love Abri Technologies "Recover" tool for Fox 2.6 (has saved our bacon from some severe table corruption in the past), and it would only be another 70 bucks to get a copy for VFP 6.0. I like SDTs recover abilities, but again, the metadata overhead makes it seem a bit less than worth it. "Recover" requires nothing more than a definition file of the tables, which can be easily obtained from our backups or daily copy folder. Also, Recover can handle a wider breadth of recovery issues, and even though the nasty problems only happen 1 or 2% of the time, I don't want to go against Murphy and have to trust a recovery tool that isn't as close to 100% as possible.
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. View updates are easy because we do all our views programmatically. Plus, the NeedUpdate() function takes over 30 seconds on our sizable database, so we would have to utilize an extended property "Updated" flag to trigger updates at the program level. As soon as the first kludge rolls in, I always worry about more to follow...

I guess I feel like am between a rock and a hard place. We have been without SDT for so long (I wish we had gotten it a year ago) that we have already automated a lot of things or handled them via standards and common practices. If I could find a way to overcome the performance issue with the database explorer it would be a huge step in the right direction. If anyone can help with that, I would be eternally grateful. And if anyone has any ideas or facts that I have overlooked, please let me know.

Thanks a lot!
Joe Kaufman
jkaufman@encompas.com