>>>I’ve run into a weird SQL problem and I’m hoping somebody knows the answer. In cleaning up a client’s application, I’ve written some generic code to make cursors returned from SQL Server updateable. Specifically, I’m setting the following properties of the cursor: Buffering, KeyFieldList, Tables, UpdatableFieldList, UpdateNameList, SendUpdates, WhereType.
>>>
>>>My code seems to work perfectly when the SQL table has a single PK field. But on tables that have a compound primary key, when I issue TableUpdate() on the cursor, I get a “Violation of PRIMARY KEY constraint” error from SQL. The Profiler tells me that it’s attempting to send an Insert rather than an Update, which seems to me to be the actual problem. For a table with a single PK field, TableUpdate() generates an Update command.
>>>
>>>I’ve checked and KeyFieldList includes both PK fields and there is, in fact, exactly one record on the back-end that matches the one in my cursor.
>>>
>>>So has anybody run into this before? Have I found an undocumented VFP bug (after all these years)? The only work-around I can think of is to detect the situation and generate the UPDATE command myself. The problem is knowing whether I need UPDATE or INSERT, which is the reason I wanted to use an updateable cursor. (I know how to write the work-around; I just don't want to.)
>>>
>>>Tamar
>>
>>Our code works perfectly fine with compound primary keys, so the problem must be in your code. You may want to post it or alternatively I can post our routine that makes SPT cursor updatable.
>
>Yours works for edits, not just for new records?
>
>Tamar

Yes, our application uses sql-pass-through, it then makes the cursors updatable and uses them. The name of the cursor should match the original name of the table. If you need our program of making cursor updatable, I'll can probably post it (although it's not my code, it was there developed long ago before I came).