通过 ODBC 调用 SQL Server 存储过程失败，留下空表
我们在 Linux 上使用 C 语言的 ODBC。我们可以使用 SQL Server 2008 和 MySQL 的 ODBC 成功执行直接语句（“INSERT ...”、“SELECT ...”等）。我们正在迁移到存储过程，因此我们首先开发了 MySQL 存储过程。使用 ODBC 调用 MySQL 存储过程是可行的。生活是美好的。
存储过程被转换为 T-SQL。我们通过直接从 Visual Studio 执行查询来验证它们是否正常工作。数据库已满，查询工作。万岁。
我们有一个测试程序，允许我们使用MySQL或SQL Server，直接执行或调用存储过程。我们从 C 测试程序中调用 T-SQL 存储过程。日志输出表明表正在填充数据，查询正在运行等。直到最后，语句失败。程序退出（比正常情况多花费几秒钟）。其他 3 种情况有效（直接 MySQL、直接 SQL Server、存储过程 MySQL）。
我们检查 SQL Server 数据库。它是空的。我们打开了自动提交，所以我认为这不是提交问题。存储过程非常简单，是直接 SQL 的副本。有什么想法吗？
We are using ODBC from C on Linux. We can successfully execute direct statements ("INSERT ...", "SELECT ...", etc) using ODBC for both SQL Server 2008 and MySQL. We are migrating to stored procedures, so we first developed MySQL stored procedures. Calling MySQL stored procedures using ODBC works. Life is good.
The stored procedures are translated into T-SQL. We verify that they function by executing queries directly from Visual Studio. The database is filled, queries work. Huzzah.
We have a test program allowing us to use MySQL or SQL Server, direct execution or calling stored procedures. We call the T-SQL stored procedures from a C test program. Log output indicates that tables are being filled with data, queries are working, etc. Until the end, where a statement fails. The program exits (taking several seconds longer than normal). The other 3 cases work (direct MySQL, direct SQL Server, stored proc MySQL).
We examine the SQL Server database. It's empty. We have autocommit turned on, so I don't think it's a commit problem. The stored procs are bog simple, being copies of the direct SQL. Any ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
听起来查询正在运行 - 然后由于某种原因出错，所有内容都被包装为单个事务 - 并回滚。因此空表。
存储过程中是否有任何错误捕获？ SQL Server 2005 及更高版本通过 TRY.. CATCH 极大地改进了错误处理。
It sounds like the query is running - then errors out for some reason, and everything is wrapped up as a single transaction - and rolls back. Hence empty tables.
Does the stored procedure have any error trapping within it? SQL Server 2005 and later improved error handling enormously with TRY.. CATCH.