On 29 Ago, 22:38, Erland Sommarskog <esq...@sommarskog.se> wrote:

>
> SqlClient does not send this by default, if you use CommandBehaviour.KeyInfo
> it does.
>
For all the docs I've seen till now, KeyInfo really seems like the
most interesting option. A couple of remarks:
1-I use an ExecuteReader with no parameters, so no CommandBehavior is
being used.
2-I do not see any "SET FMTONLY OFF" being executed, despite some
people complaining about that on the net. If one sees
http://msdn2.microsoft.com/en-us/lib...dbehavior.aspx
it would also be appearing in my case.

I'm now looking into the SqlCommand and SQLConnection classes to see
if something can make the "SET NO_BROWSETABLE ON" disappear. Anyone
got a clue?

rj

(raymond_b_jimenez@yahoo.com) writes:
> For all the docs I've seen till now, KeyInfo really seems like the
> most interesting option. A couple of remarks:
> 1-I use an ExecuteReader with no parameters, so no CommandBehavior is
> being used.
> 2-I do not see any "SET FMTONLY OFF" being executed, despite some
> people complaining about that on the net. If one sees
> http://msdn2.microsoft.com/en-us/lib...dbehavior.aspx
> it would also be appearing in my case.
>
> I'm now looking into the SqlCommand and SQLConnection classes to see
> if something can make the "SET NO_BROWSETABLE ON" disappear. Anyone
> got a clue?

Since I don't see SET NO_BROWSETTABLE ON in my test setup, it's a bit
difficult to advice. Maybe you can post a sample program which produces
the dreaded NO_BROWSETABLE? Preferrably this should be a simple
command-line program without GUI.


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

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx

There is some hope... I've put my code in a new test environment, and
it does not issue "SET NO_BROWSETABLE ON". I've debugged the situation
further, and found some interesting differences doing some networking
debugging (using Wireshark):

-When I connect in the production environment, the one that gets "SET
NO_BROWSETABLE ON", the "App Name" is set to "Microsoft (R) .Net
Framework" and "Library Name" is set to OLEDB
-When I connect in the testing environment, both "App Name" and
"Library Name" are set to ".Net SqlClient Data Provider".

The "App Name" that appears in Wireshark is the same that appears in
SQL Profiler.

An adapted code example follows:
-----------------------------------------
Dim SQLConx As SqlConnection = New SqlConnection
Dim SQLCom As SqlCommand = New SqlCommand
Dim SQLDR As SqlDataReader

Try
SQLCom.Connection = SQLConx
SQLCom.CommandType = System.Data.CommandType.StoredProcedure
SQLCom.CommandText = "myStoredProcedure"
SQLCom.Parameters.Add("@param", _param)
SQLConx.ConnectionString = SQLConnectionString
SQLConx.Open()
SQLDR = SQLCom.ExecuteReader()
SQLConx.Close()
Catch exc As Exception
-----------------------------------------

What's stranger is the OLEDB reference. I'm not using it in my code,
but it appears in the network trace. What might I be missing?

rj

(raymond_b_jimenez@yahoo.com) writes:
> -When I connect in the production environment, the one that gets "SET
> NO_BROWSETABLE ON", the "App Name" is set to "Microsoft (R) .Net
> Framework" and "Library Name" is set to OLEDB

Apparently you are using OleDbConnection etc in production. With OleDb
Client you may experience NO_BROWSETABLE more often.




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

Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/pro...ads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinf...ons/books.mspx