Another thought ...
I wonder if it's really necessary to create this candidate key after all.
SWare, the only reason you need the key is so that your RecordSet object can use it in its WHERE clause, in place of all the separate fields that you had originally. Given you have a unique identifier for the record (I assume that's what GS_ID is), you should be able to simply tell your RecordSet that this is the primary key. (We still don't know how to do that, but that's a separate issue.)
In other words, you fool the RecordSet into thinking that GS_ID is a primary key -- even if it isn't. The RecordSet will go ahead and generate the correct WHERE clause, which the OLE DB driver should have no dificulty in interpreting.
The fact that this is not really the primary key shouldn't matter. There are however two caveats:
- GS_ID has really got to be unique. If it isn't, you'll be updating multiple records.
- The update will take longer, as Foxpro will have to look at each record in turn until if finds the one that needs updating.
Understand, I'm not completely sure about any of the above. But it must be worth a try.
Mike
__________________________________
Mike Lewis (Edinburgh, Scotland)
My Visual FoxPro site: www.ml-consult.co.uk