从 .NET TableAdapter 更新 XML 列时出现问题
我正在尝试更新 SQL Server 2005 表中的 XML 列。通过存储过程访问此列。我正在使用 .NET tableAdapter 来调用此过程。 问题:xml 列的值未更新。
一些观察:
- 我使用 SqlProfiler 来查看存储过程调用是否确实发送到 SQL Server。情况就是这样。
- 我还直接从 SQL Server Management Studio 中执行存储过程调用。完成此操作后,将执行存储过程。
这可能是 .NET tableAdapter 使用的参数有问题吗?在我看来,这是与 SQL Server Management Studio 调用的唯一区别。
这是列表:
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read uncommitted
I'm trying to update an XML column in a SQL Server 2005 table. Access to this column is through a stored procedure. I'm using a .NET tableAdapter to call this procedure.
The problem: The value of the xml column does not get updated.
Some observations:
- I used SqlProfiler to see if the stored procedure call is actually sent to the SQL Server. This is the case.
- I also executed the stored procedure call directly from within SQL Server Management Studio. When done this way, the stored procedure is executed.
Could this be a problem with the parameters the .NET tableAdapter uses? That would be the only difference with the SQL Server Management Studio calls in my view.
Here is the list:
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language us_english
set dateformat mdy
set datefirst 7
set transaction isolation level read uncommitted
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
当您尝试手动执行存储过程时,您是否使用了应用程序的表适配器所使用的相同用户凭据?如果没有,请尝试模拟用户,然后查看是否可以看到应用程序当前未捕获的错误。
说到这里,您的应用程序代码中是否有围绕数据库请求的异常处理?可能会出现错误,但由于您没有捕获错误而被忽略。
When you tried executing the stored proc manually, did you use the same user credentials that your application's table adapter is using? If not try impersonating the user and see whether you then can see an error which your app isn't currently catching.
Speaking of which, do you have exception handling in your app code around the database request? It could be that an error is being raised but ignored because you aren't trapping it.