>>Thanks, Ed --- I kinda thought I'd have to do that, but it never hurts to ask!
>>
>
>This is one of the things that makes a strong case for SDT; with SDT, you could simply send out the updated metadata tables (.DBFs that contain extended information about the .DBC and its tables, view and indexes) and fire a method you can build into your app; instant updates, not just to indexes, but also revied field, table and view definitions can be incorporated relatively painlessly, and the code is pretty bulletproof!
>

I tried using SDT for a while on one site, and had to ditch it because it was too damn SLOW. I have a feeling this is not Doug's fault but VFP's: I have found while building and using eView that a bunch of DBSETPROPS and DBGETPROPS can be pretty taxing timewise.

Anyway, the reason am posting is that my strategy now works just as well for me as SDT did for maintaining multiple copies of datastructures:

1. Initially create all tables using the designer.
2. Use GenTable to write code to create them. Same for views.
3. Any modifications that have to made to table structure, indexes or views after initial creation are made programmatically.

This program then serves as the synchronization routine. Sure, you have to familiarize yourself with the entire VFP DDL, but you should anyway.