>>>Could it be that your table was involved in persistent relationships? In this case you can not remove primary key.
>
>Hi Naomi,
>
>I don't think that's the case: First, There's not any relations between my tables other than the ones I enforce via hard-coding in my app. I had such bad experiences with VFP RI management in my beginnings that I left it out of that domain altogether. I have no problem with removing the primary key, it's when I add my regular index that I get a problem: it works fine in the development environment, but a "candidate" key is created when I try the same code in the app.
>
>>>Try using TRY/CATCH and show error messages.
>
>I'm already doing that bit in a Try/Catch block (though I didn't show it in my post), that's why I have an type-exception variable declared at the beginning of my routine. But it doesn't catch anything.
>
>My goal is to modify my client's tables' structure (remove a primary index, then add a regular one on the field) when they unzip their backup DB in the patched app, but I always end up with a candidate key instead of a regular one even if I don't use the "CANDIDATE" keyword.
>
>I'm confounded!
>
>Thanks again,

I see the problem better now and from the description it sounds like some weird bug.

Ok, now questions.
1) How many indexes this table has?
2) Is it part of DBC?
3) Instead of ALTER TABLE, can you open the table exclusively, remove PK using DELETE TAG command, then create it?

Or may be DELETE TAG ALL, then re-create? Just an idea. Is database on the Network? It may be something is still in memory when you're trying to do things in this sequence.