Posted by Erland Sommarskog on 09/01/07 22:59

Stephen Howe (stephenPOINThoweATtns-globalPOINTcom) writes:
>> And as I've noted in another thread, SqlClient does not do this when
>> you use it plainly. Run a plain ExecuteReader or DataAdapter.Fill and
>> you will not see it. There was a link posted that lead to an article
>> pointing out the problem with the CommandBuilder.
>
> Can you get classic ADO and SQLOLEDB in combination not to do that?

Yes, don't use it.

Seriously, it's is very difficult to get ADO only what it supposed to
and not a lot more. For instance, say that you set up a Command object
to call a stored procedure with a number of parameters. The first call
is clean, just a direct RPC call. But if you keep the object to call
the procedure again with different parameters, ADO now issues SET FMTONLY
ON to get some information about the result sets. And if you think that
NO_BROWSETABLE is bad, you should know that FMTONLY causes SQL Server to
sift through the statements in the procedure in a sort of half-NOEXEC
mode.

I did some quick testing with a some sort of general test app that I have
for ADO, and it appears that you get the browsetable stuff when you
request a lock type other than ReadOnly. If you perform your updates
through stored procedures, I see no reason why you should use anything
but ReadOnly and implement optimistic locking yourself.


--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx

[Back to original message]