Mark,

>I don't have near the time wait you are axperiencing in opening the SDT explorer. Do you have SDT installed on your local drive? I am thinking you may have to rethink how you are doing all those changes to the database. Tables, file structures and indexes should be fairly stable after a reasonable period of time. If your other developers are using SDT to make these changes, you need to purchase a SDT license for each.

Yes, I know we would have to purchase licenses (that's what I was balking against).

And yes, the database models will stabilize eventually, but we still have a good two months of heavy development to go, and I don't see things stabilizing any time soon.

"Rethink how we are doing changes to the database"...I guess you lost me here. The changes do not appear to have anything to do with the Explorer being slow. I can open the database, then close it, then open it again with no changes -- 5 minutes every time. When I did change a table outside of SDT the open took longer because it found the changes and placed them in the extended neta-data. It would seem that upon opening the Explorer, SDT is doing a pseudo-validate without me asking for it, and that is probably slowing it down. How big is your database? Is there a way to make SDT open without it doing any validations?

>I suspect SDT explorer is slow instanciating because it is having to run through validation from all the changes made to the DB outside of SDT. If you use SDT to make changes to your tables, indexes, views, etc., startup should be faster.

As I said above, even with no changes it takes 5 minutes to open.

>In your automatation of rebuilding indexes, etc., did you build in the recreation of PK, FK, persistent relations as well? How do you handle DB updates to your customers? My SDT license has more than paid for itself in saved time in all these areas.

My reindex will handle all that no prob. I spent about an hour working on that yesterday, and I probably have about 2 more hours left (we already had a generic reindexer for our existing application, so the rough framework was there). Maintaining relations and such should be straightforward. If all else fails, I can just save off all "Relation" records in the DBC and put them back when I am done...unless I am really missing something, reindexing is not a complicated process, even in VFP?

As for customer updates, as you said, once the design stabilizes, these changes are few. Most changes will involve view changes (which are not difficult since we do them programatically and can be done on the fly) or the addition of tables (which is easy...just move in the new empty table). The only tricky things are table structure changes, and if we have those we just write a quick program to alter the table accordingly, or just make the changes at the client's site remotely. I don't disagree that SDT's Update function is probably the coolest thing about it, I just don't like the meta-data overhead (yes, I am whining...how can I expect to get the good stuff without having a bit of extra overhead...I guess I just don't see it as being worth it).

>Having 10 additional metat data files is nothing to me. I just bundle them up in a zip file with the DBC, DCX and DCT files and download them to my customers. My app will detect this file, use DynaZip to unzip it to the database folder, then run the SDT database validation procedure. No fuss, no muss.

I am glad it works for you. With 5 database containers in various directories, I worry about all the files getting to the right spots (all metafiles have the same names...yes, I can probably change that, but there's another customization). Also, we keep everything under source control, including meta-files so that we can always do a roolback and see what has changed, etc. Whereas checking in the database now requires manipulation of 6 files (the three DBC files, the PRG and KRT from GENDBCX, and our ADDVIEWS program), it would require checking in/out 16 files with SDT. I worry about our developers (me included) not getting all the files checked out appropriately and being left with half-baked metadata. Another question, is there something like GENDBCX that can make one big program that will generate the entire database as well as the extended DBCX2 metadata? If one PRG could be checked in instead of having to check in the actual meta-files, that would be pretty sweet. I didn't see anything in the manual about being able to generate programmatic meta-data...

Thank you for your comments! If you have any other ideas on why SDT might be opening so slow for us, please let me know! I am glad the tool is meeting your needs!

Thanks,
Joe Kaufman
jkaufman@encompas.com