Doug,

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

Hey, don't worry about it...been keeping plenty busy myself. By the way, great job in FoxTeach...the two seminars I went to of yours were worth the price of the show right there *smile*.



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

Yes, the DB is big. Any idea how much faster the new version will be and when it is coming out? As my later comments bear out, because of our situation, the slowness of the visual environment will probably cause us to "give up" on the tool (for now).

>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

OK, that works. But I still have the burden of knowing what other developers have changed (unless we spend $1000 more so everyone has SDT) so that I can validate those items singly. That is the part that worries me. It also worries me in terms of training. We have 3.5 developers here now, and could potentially have a couple more in the relatively near future. Having to train them on the object structure of the SDT tool is just another thing for everyoneto learn. This is why we shied away from commercial frameworks-- the fear of spending more time trying to learn a huge package that was either overkill or not flexible enough. True, I still need to go around explaining my Joe-framework to the other guys, but it is very simple and catered to our exact needs...

That was all just a wordy way of saying that the package starts to look a lot less attractive without the visual front-end. I don't mean that as an insult...on the contrary, the visual aspect is so incredibly easy to use and is so nice to have all in one spot that it is painful to have to "degenerate" back to coding to get things done...

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

Yes.


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

Yes, I would have to agree with you. I guess the metadata just seems like overkill for our needs. I know it is a great structure and can do almost everything, it's just that we simply don't need everything...

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

My bad...this is a good point, and will make me look into the update capability a bit more.

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

I can see your point, but at the bottom line, can't you just copy the DBC files back into place to recover from what happened (at the worst you will have lost the indexes for one file if you abort when the thing goes wrong)? I don't doubt the vast reindexing capabilities of SDT -- again, it is just a metadata (and the burden of maintaining it, especially without a visual tool) vs. functionality question.



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

Well, that depends on how you write your update procedures, doesn't it? *grin*

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

I agree with everything you have said, but would really like the visual front-end to ease development for our develoment crew. If it was just me I wouldn't hesitate to do everything via the object methods and such. If the next version is as fast as it is looking to be, we will give it another look.

Thank you for your response in this matter...

Joe Kaufman
jkaufman@encompas.com