Yup John remember alot of ADO.NET was taken from VFP, Linq is nothing more then try to bring the easy of VFP to work with data into the .NET world.

>Alex,
>
>OK, that makes sense... The problem I have had is with explicitly sending NULL, not leaving it out. I am able to INSERT explicit NULLS using ExecuteNonQuery(), but even that will throw data type mismatch errors. Better to just handle the NULLs in our DBF data, and with the parameters being defined in the InsertCommand and UpdateCommand with proper type, it is easy to generate an "empty" value for each.
>
>Also, the more I read about ADO.NET and play with it, I realize how much it is like VFP in a very important way: there are many, many different ways to do a task. *smile* I have not even gotten to the point of using each DataRow or tapping into the events that fire, and ADO.NET has me 90% of the way to doing everything we need...
>
>Thanks to everyone for their help!
>
>JoeK
>
>>Joel this work fine with insertcommand and updatecommand as long you open the connection prior to using the dataadapter, remember that the dataadapter will open and close the the connection in case it wasn't open at prior.
>>Now this will work for fields missing on the insert/update command, will not work if you put a null value on that field, or fiel.ds that you didn't set the value.
>>What I do in that case is that I have a method that goes over each row and col and sets default values or blank ones in case no default value exist.
>>
>>
>>>Alex,
>>>
>>>Does this work for commands that become InsertCommands or UpdateCommands? I can get the SET commands to stick when I just do straight SQL statements (like running an INSERT command directly through the CommandText of a SelectCommand).
>>>
>>>But when I fill a DataTable and then set the InsertCommand of the data adapter, NULL values trigger an error when the Update method tries to insert a new record...
>>>
>>>Do you use your Command objects with the Update method and have it work?
>>>
>>>Thanks,
>>>JoeK