Mike,

The CommandBuilder is gnerating very long command statements that the OLE DB provider can't handle. I think you should just plan on writing your own Command statements to Insert/Update/Delete.

>Ok,
>
>Well it's a step in the right direction :)
>
>The .UpdateCommand did seem to get updated properly. and the DataAdapter.Updates completes without an error. (but no data has changed yet...)
>
>
>I addded the line:
>
>m_DataSet.Tables["Customer"].Rows[1]["country"] = "USA";
>
>to force a change. Now I'm getting an exception error thrown of "SQL:Statement too long" :(
>
>The table itself has 50 fields and their names aren't that long
>
>Is it me, or does it seem like it allways two steps forward and one back, I just can't seem to catch a break!
>
>So now I presume the SQL generated by the command builder is too long for VFPOLEDB.DLL to handle? Please tell me I'm not at a dead end.
>
>Two other questions,
>1) I like the previous way you showed to define the column that is primary, do you know any tricks for tables that have no unique keys. In the old Foxpro\VFP days we would seek Recno() to go back to the Record number.
>
>2) I havent had any problems using ADO with VB6 to update these tables. I know that's because ADO (2.5\2,6) doesn't disconnect the recordset like ado.net does. I have read a few articles regarding using ADO recordsets in Dotnet - Does this method have any merit. I would Like to do things the "Dotnet-Way", I just seem so close (again & again) that I don't want to give in and take a step backwards.
>
>
>I think I owe you a drink, or perfume or something by now, you've been an real help.
>
>Thanks again,
>Michael