>>>Yeah, but you lose any primary key, candidate key, persistent relationships, RI, etc. That's why I suggest Stonefield. This deletes the indeg tag (all), rebuilds the indexes, recreates the primary key, RI, etc. It also provides a pack option as well. Allows for updating table structures by comparing new metadata files to what is in current DBC and tables. If updates are needed, it does them for you. It's a slick tool, and I rely on it heavily to keep my vastly distributed customer base (every southern border State from S California to Florida and now Georgia).
>>
>>Didn't consider the related tables issue. I work mostly with flat tables. Still there should be a work around for this. I can see, however, where, in your situation, that a product like Stonefield would be almost a must.
>
>I wrote a PRG that stores the TAGs info for a table, deletes all tags then recreates them from scratch. Not as sophisticated as some of the commercial tools, but it works and it's cheaper. :-) Of course the commercial tools are generally hard to beat since that's their business.

Problems with indexes was one of the first things that I tackled back when I wrote my first framework in FPD 2.0. What I did was to create a table for each system that stored the necessary information to re-build all index tags for each table in the system.

This thread has reminded me that VFP's DBC stores information that I'll need to access for some systems. Thanks, Mark.