>In the situation I'm in, it's not as simple as a primary key deletion via stored proc. There *is* a stored proc for deletions that accepts the PK. Getting to that point is the issue.
>

Okay....



>It's an incoming text file with about 70 columns that has to be validated and pumped over to the server db (or delete or change existing records)....since the server db generates the PK via an identity, the text files to not have a PK. So I have to go looking for the PK using a composite key that should be unique. Then I can take advantage of the SP and PK.
>

So you need to take info from the text file to get the PK? Sounds like you could do this in 2 disctinct processes. First, get the PK's. Second, perform the delete. Is this an ongoing process?


>Now, in the past, everything was SPT. The major problem there was that UPDATEs had to be done via multiple UPDATE statements because these 70 columns have long field names and there's that old ODBC 254 character limitation. And they don't have an SP for update because of the huge number of parms that would be required.
>

Okay...


>So, what's going to make this work for me on this conversion to ADO is this simple question: Is there any limit to the size of the Command.CommandText property? If not, then I can collapse all those SQLEXEC UPDATE statements into a single Command objects CommandText and Execute and that is bound to be much more efficient.
>

The commandtext will be very small. Remember, you have a parameters collection that will hold your individual parameters...