Ah, now we hear the rest of the story. <g> If I recall correctly (and this old brain is starting to forget things, so forgive me if I've got the particulars mixed-up), this is one of the reasons that using the CommandBuilder with VFP is problematic.

If you don't have any PK's then you can't use the CommandBuilder and you'll have to roll your own, as I've suggested in a few of my other posts lately. I don't have time at the moment to look for links to those posts (I'm late for an appointment), but I'll post some links when I return, if you haven't found them yourself.

~~Bonnie


>It is #2, it is a free foxpro table with no index/primary key data, that is why I want to somehow specify the primary key manually. The equivilant of CursorAdapter.KeyFieldList in VFP. If I add a candidate index to CO_ID in one of the tables the error then switches to "SQL: Statement too long."
>
>>Patrick,
>>
>>As it turns out, I don't think setting the Primary Key on the DataSet's DataTable is absolutely necessary (I tried without and it worked fine) ... sorry about that ... as I said, I don't use the CommandBuilder at all and I also don't use PK's in my DataSet (database, yes, but not in the DataSet).
>>
>>>Thanks, I am still getting this error: Dynamic SQL generation for the UpdateCommand is not supported against a SelectCommand that does not return any key column information.
>>
>>Your problem is one of two things ...
>>
>>1) You are not returning the CO_ID in your Select statement.
>>2) Your database does not consider CO_ID to be a Primary Key.
>>
>>~~Bonnie
>>