如何诊断 SqlDbType 上的 ArgumentOutOfRangeException?

发布于 2024-07-15 22:53:06 字数 1618 浏览 5 评论 0原文

我们有一些使用 .NET 2.0 胖客户端应用程序的客户在从 SQL 2000 SP4 Server 读取数据时遇到奇怪的间歇性错误,而操作刚刚成功。 我们有一些客户使用 SQL 2000(许多客户使用 2005),但不会发生这些错误。

我注意到的一件事是,我们的测试环境中的应用程序引用了 System.Data 2.0.50727.3053; 而应用程序在客户系统上引用 2.0.50727.1433。 这两个修订版之间有什么区别?是否与下面描述的错误有关?

下面是错误堆栈跟踪的示例,其中枚举值为 8,但我还有更多实例,其中“越界”枚举值为 4 或 14,且堆栈跟踪完全相同。 是否有时可以找到枚举值,但有时却找不到? 如果应用程序的同一部分运行没有错误怎么办?

TYPE: System.ArgumentOutOfRangeException
MSG: The SqlDbType enumeration value, 8, is invalid.
Parameter name: SqlDbType
SOURCE: System.Data
SITE: GetSqlDataType

at System.Data.SqlClient.MetaType.GetSqlDataType(Int32 tdsType, UInt32 userType, Int32 length)
at System.Data.SqlClient.TdsParser.CommonProcessMetaData(TdsParserStateObject stateObj, _SqlMetaData col)
at System.Data.SqlClient.TdsParser.ProcessMetaData(Int32 cColumns, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.NextResult()
at Ceoimage.Basecamp.Data.Document._GetDocumentModelWithCollections(IDataReader rdr)

更新:我刚刚从客户的工作站之一下载了 System.Data。 它们在 GAC 中有两个版本,一种在 GAC 目录中,一种在 GAC_32 目录中。 在GAC中,版本号为1.14322.2365。 在 GAC_32 中,版本号为 2.0.50727.1433,如上所述。 然而,在所有三个版本中,SqlDbType 枚举将相同的 int 值映射到错误消息中的相同类型:

DateTime = 4
Int = 8
UniqueIdentifier = 14

我担心该版本可能是一个红鲱鱼:如果问题与框架版本有关,则不应该问题100% 都会发生而不是暂时的?

We have some customers using our .NET 2.0 thick-client app that experience strange, intermittent errors reading data from a SQL 2000 SP4 Server, where the actions succeeded just moments earlier. We have some customers using SQL 2000 (and many using 2005) where these errors do not occur.

One thing I notice is that the app in our testing environments references System.Data 2.0.50727.3053; whereas the app references 2.0.50727.1433 on the customer's systems. What is the difference between these two revisions and could it be related to the errors described below?

Here is an example of the error's stack trace where the enumeration value is 8, but I have plenty more instances where the "out of bounds" enumeration value is 4 or 14 with the same exact stack trace. Are the enumeration values findable sometimes but not at other times? What about when the same portion of the app runs without errors?

TYPE: System.ArgumentOutOfRangeException
MSG: The SqlDbType enumeration value, 8, is invalid.
Parameter name: SqlDbType
SOURCE: System.Data
SITE: GetSqlDataType

at System.Data.SqlClient.MetaType.GetSqlDataType(Int32 tdsType, UInt32 userType, Int32 length)
at System.Data.SqlClient.TdsParser.CommonProcessMetaData(TdsParserStateObject stateObj, _SqlMetaData col)
at System.Data.SqlClient.TdsParser.ProcessMetaData(Int32 cColumns, TdsParserStateObject stateObj)
at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
at System.Data.SqlClient.SqlDataReader.NextResult()
at Ceoimage.Basecamp.Data.Document._GetDocumentModelWithCollections(IDataReader rdr)

Update: I just downloaded System.Data from one of the clients' workstations. They had two versions in the GAC, one in the GAC directory and one in the GAC_32 directory. In GAC, the version number is 1.14322.2365. In GAC_32, the version number is 2.0.50727.1433 as described above. In all three versions, however, the SqlDbType enumerable maps the same int values to the same types for those in the error messages:

DateTime = 4
Int = 8
UniqueIdentifier = 14

I am afraid the version might be a red herring: if the problem has to do with framework versions, shouldn't the problem happen 100% of the time rather than being transient?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

夏了南城 2024-07-22 22:53:06

这个古老的讨论跟踪使用在一个线程上创建的连接在不同线程中运行查询时会出现类似的错误。 SqlConnection “不保证实例成员是线程安全的” 。 如果您的应用程序是多线程的,请确保正确使用连接。

该问题也可能是 SQL Server 端的问题,该问题已在最新版本中得到解决。

我在这里回答是因为我在将 SqlCommand.Cancel 与 SQL 2005 一起使用时遇到了此错误。(除了“用户取消操作”之外,根据取消查询的时间,还会发生一些异常。)我看到它作为“服务器的意外响应”错误...如果确实发生,清除连接池可能是个好主意。

如何取消长时间运行的数据库操作?

如何强制 SqlConnection使用连接池时物理上接近?

This ancient discussion tracks a similar error down to using a connection created on one thread to run a query within a different thread. SqlConnection "instance members are not guaranteed to be thread safe". If you application is multi-threaded, make sure connections are used properly.

The problem may also be something SQL-Server side that has been resolved in more recent versions.

I am answering here because I've encountered this error when using SqlCommand.Cancel with SQL 2005. (There are a handful of exceptions that occur in addition to 'Operation cancelled by user' depending on when the query is cancelled.) I see it as a 'unexpected response from the server' error... it's probably a good idea to clear the connection pool if it does happen.

How to cancel a long-running Database operation?

How to force a SqlConnection to physically close, while using connection pooling?

℉服软 2024-07-22 22:53:06

您的客户端使用的是 .NET 2.0,未安装 3.5。 您的测试服务器是 3.5。 3.5 中添加到枚举中的唯一内容是:

Structured
Date
Time
DateTime2
DateTimeOffset

这并不意味着没有一些潜在的更改。

如果可能的话,我会在不安装 3.5 的情况下在 2.0 下测试该应用程序,看看会出现什么错误。 这应该会给你一个很好的起点。

为了找出错误点,我必须迭代枚举并查看枚举中项目的顺序。 Reflector 是执行此操作的绝佳工具,但您必须在 2.0 系统和 3.5 系统上执行此操作才能看到更改。

Your client is on .NET 2.0 without 3.5 installed. Your test servers are 3.5. The only things added to the enumeration in 3.5 are:

Structured
Date
Time
DateTime2
DateTimeOffset

This does not mean that there are not some underlying changes.

If possible, I would test the app under 2.0 without 3.5 installed and see what errors you are getting. That should give you a good place to start.

To figure out the point of error, I would have to iterate through the enumeration and see what order the items are in the enum. Reflector is a great tool for doing this, but you will have to do it on both a 2.0 system and a 3.5 system to see the changes.

烟酒忠诚 2024-07-22 22:53:06

解决方案可以解决您的问题:

您的本地机器使用的是 SQL Server 2008,但另一个机器使用的是 2005? @RUNTIME 参数的类型为 SqlDbType.Time。 该类型在 SQL Server 2005 中不存在。此外,正如异常所示,SqlDbType.Time 的值为 32。 在 sql server 2008 之前,您不能只存储时间值。在 2005 年,您必须将 @RUNTIME 存储为 SqlDbType.DateTime。

如果您使用 .NET Framework 2.0,则必须安装 .NET Framework 2.0 SP2和sql2008解决了这个问题。

this solution may solve your problem:

Is your local box using SQL server 2008 but the other box is 2005? The @RUNTIME parameter is type SqlDbType.Time. That type did not exist in SQL server 2005. Also SqlDbType.Time has a value of 32 as the exception says. You can't store just time values before sql server 2008. You have to store @RUNTIME as a SqlDbType.DateTime in 2005.

And if you use .NET Framework 2.0 use must Install .NET Framework 2.0 SP2 and sql2008 to solve this problem.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文