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

The new version also supports free tables, so updated free table structures and tags are easy, too. It's one add-on that's paid for itself many, many times over for me by now, and provides some incentive to get a PUTM - the discount for PUTMs purchasing SDT about covers the yearly cost of PUTM!

>Bonnie
>
>>>Hi guys --
>>>Quick question. In one of my tables in my database, I had set up an index to be a candidate index. Today I realized it should merely be a regular index, so I changed it. My question is this: is this change reflected in the DBC only? Can I safely give my customer the updated DBC without causing problems in the affected table?
>>>
>>
>>You really need to recreate the index, and rather than sending out a new .DBC, you'd be better off making the change programmatically using the ALTER TABLE...DROP UNIQUE TAG to remove the candidate key, and then recreating the index tag.