使用 osql 和 sqlcommand 时的 SQLServer 2005 行为差异
有谁知道通过 OSQL 执行命令与使用 SQlConnection 执行编程查询时 SQL Server 2005 的行为之间存在任何细微差别吗?
我有一个客户端,其数据库位于远程计算机上,我可以使用 OSQL 与之交互。但是,当我通过构建 sqlconnection/sqlcommand 尝试类似的查询时;我收到错误:
['建立与 SQL Server 的连接时发生与网络相关或特定于实例的错误。服务器 未找到或无法访问。验证实例名称是否正确,以及 SQL Server 是否配置为允许远程连接(提供程序:SQL 网络接口,错误:26 - 定位服务器/实例特定错误)。
这是有效的 OSQL 命令:
osql -S myHost\SQLEXPRESS -U sa -q "USE [TempDB] select [Endpoint] from [Service]"
这不起作用,会生成上述错误。
SqlConnectionStringBuilder cnBldr = new SqlConnectionStringBuilder();
cnBldr.UserID = "sa";
cnBldr.Password = "PASSWORD";
cnBldr.DataSource = "myHost\\SQLEXPRESS";
cnBldr.InitialCatalog = "TempDB";
using (SqlConnection cn = new SqlConnection(cnBldr.ConnectionString))
using (SqlCommand cmd = new SqlCommand("select [Endpoint] from [Service]",cn))
{
cn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
rdr.Read();
}
在这两种情况下,我都以同一用户身份运行(即:我以 Windows 用户身份登录,然后打开 cmd 窗口并执行 OSQL 命令,或者启动包含上述代码片段的 Windows 应用程序。OSQL 将运行,代码片段生成上述错误。OSQL 片段将提示用户输入密码,
这可能会导致此行为。不相信这是由于以下问题造成的连接数,因为我可以在执行 osql 命令(它将起作用)和运行应用程序(它将生成错误消息)之间自由切换,
的任何想法。
感谢您
Is anyone aware of any subtle differences between the behavior of SQL Server 2005 when executing a command via OSQL vs. a programmatic query using SQlConnection?
I have a client with a database on a remote machine that I can use OSQL to interact with. However, when I attempt a similar query via building a sqlconnection/sqlcommand; I receive the error:
['A network-related or instance-specific error occurred while establishing a connection to the SQL Server. The server
was not found or was not accessible. Verify that the instance name is correct and that the SQL Server is configured to allow remote connections (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specific).
Here is the OSQL command which works:
osql -S myHost\SQLEXPRESS -U sa -q "USE [TempDB] select [Endpoint] from [Service]"
This doesn't work, the error above is generated.
SqlConnectionStringBuilder cnBldr = new SqlConnectionStringBuilder();
cnBldr.UserID = "sa";
cnBldr.Password = "PASSWORD";
cnBldr.DataSource = "myHost\\SQLEXPRESS";
cnBldr.InitialCatalog = "TempDB";
using (SqlConnection cn = new SqlConnection(cnBldr.ConnectionString))
using (SqlCommand cmd = new SqlCommand("select [Endpoint] from [Service]",cn))
{
cn.Open();
SqlDataReader rdr = cmd.ExecuteReader();
rdr.Read();
}
In both cases, I am running as the same user (ie: I log in as a windows user and I either open a cmd window and execute the OSQL command or I launch a windows application which contains the code fragment above. The OSQL will work, the code fragment generates the error above. Both cases utilize the 'sa' account for accessing the database. The OSQL fragment will prompt the user to input the password.
Is there some difference between the two that could attribute to this behavior? I don't believe that this is due to a problem with the number of connections as I can freely switch between executing the osql command (which will work) and running the application (which generates the error message).
Thanks for any thoughts.
-john
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
首先不要使用
TempDB
,名称为tempdb
,您的代码将在区分大小写的实例上中断。对于连接问题,请按照 SQL 网络接口,错误:26 - 定位指定的服务器/实例时出错。 OSQL 使用 ODBC,而 SQLCommand 有内置的托管 SNI 实现,因此它们之间存在差异,并且它们受不同机器全局配置设置的影响。按照链接文章中的步骤操作来确定连接中断的位置。
First don't use
TempDB
, the name istempdb
and your code will break on a case sensitive instance.For the connectivity issue, follow the steps in SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified. OSQL uses ODBC and SQLCommand has a built-in managed SNI implementation, so there are differences between them, and they are subject to different machine global configuration settings. Follow the steps in the linked article to identify where does the connectivity breaks.
事实证明,这两种机制没有区别。该应用程序的启动方式略有不同;这种差异(特别是生成查询之前的名称解析)是导致错误消息的原因。
从这个角度来看,osql/sqlcmd 和编程查询之间没有本质区别。
As it turns out there is no difference between the two mechanisms. The application was being launched slightly differently; and this difference (specifically a name resolution prior to the query being generated) was what led to the error message.
There are no inherent differences between osql/sqlcmd and a programmatic query from this point of view.