尝试针对 SQl Server 2008 编写单元测试时出现先有鸡还是先有蛋的问题(恢复数据库)

发布于 2024-10-10 09:59:54 字数 669 浏览 5 评论 0原文

好吧,它们不是单元测试,而是端到端测试。设置有些复杂。单元测试将使用C#、ODBC 连接。每个单元测试都会尝试自行清理,但每 20 个测试左右(每个 C# 类一次),我们就需要执行完整的数据库恢复。根据此文档,我认为我无法通过 ODBC 连接来完成此操作:

http://www.sql-server-performance.com/articles/dba/Obtain_Exclusive_Access_to_Restore_SQL_Server_p1.aspx

消息 6104,级别 16,状态 1,第 1 行 无法使用 KILL 杀死自己的 流程。

不过,我希望 199 次测试不会因为清理不当而失控。还有别的办法吗?也许我可以打开一个不同的“连接”,例如使用 COM 自动化或类似的东西,然后从那里终止所有数据库连接?如果是这样,我该怎么做?

另外,客户端是否能够在恢复后自动重新连接,或者我是否必须每 20 次测试左右拆除一次所有内容?

如果您觉得这个问题令人困惑,请告诉我您的问题是什么。谢谢!

Ok, they are not unit tests but end-to-end tests. The setup is somewhat involved. Unit tests will use C#, ODBC connection. Every unit tests will try to clean up after itself, but every 20 tests or so (once per C# class) we would need to do a full database restore. I do not think I can do it over an ODBC connection, according to this document:

http://www.sql-server-performance.com/articles/dba/Obtain_Exclusive_Access_to_Restore_SQL_Server_p1.aspx

Msg 6104, Level 16, State 1, Line 1
Cannot use KILL to kill your own
process.

However, I would like to, so that 199 tests do not go amok because of a bad clean-up. Is there another way? Perhaps I can open a different "connection" such as use COM automation or something of that sort, and then kill all database connections from there? If so, how can I do that?

Also, will the clients be able to re-connect automatically after a restore, or would I have to dismantle everything once every 20 tests or so?

If you find this question confusing, please let me know what your questions are. Thanks!

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

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

发布评论

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

评论(2

岁月打碎记忆 2024-10-17 09:59:54

如果您可以确保可以正确关闭 ODBC 连接,则出于 C# 集成测试的目的,您可以直接使用 ADO.NET 对池中的新连接执行恢复。

我认为如果您切换从快照恢复而不是完整备份,您可能会发现速度并没有快多少。

If you can make sure you can properly close your ODBC connections, for the purpose of your C# integration tests you could use ADO.NET directly to perform the restore on a new connection from the pool.

I think if you switch you restoring from snapshots rather than full backups, you might find t much faster.

枫以 2024-10-17 09:59:54

当然,您可以从 ODBC 连接恢复。如果您正在使用尝试恢复的数据库,则无法恢复,但将上下文更改为 tempdbmaster 是微不足道的:

USE [tempdb];
RESTORE DATABASE foo FROM ...;

如果有其他连接使用该数据库数据库,它们将是您自己的连接,因此只需确保正确关闭它们即可。如果您使用连接池,请清理池。 SqlClient 使用 SqlConnectionClearAllPools,ODBC 使用 OdbcConnection.ReleaseObjectPool 达到某种类似的效果。重点是这一切都在你的控制之下。

顺便说一句,您使用 ODBC 而不是 SqlClient 的原因是什么?

Of course you can restore from an ODBC connection. You cannot restore if you are use-ing the databse you are trying to restore, but is trivial to change context to tempdb or master:

USE [tempdb];
RESTORE DATABASE foo FROM ...;

If there are other connections that use the database, they would be your own connections, so its just a matter of making sure you close them properly. If you use connection pooling, clean the pool. SqlClient uses SqlConnectionClearAllPools, ODBC uses OdbcConnection.ReleaseObjectPool to a somehow similar effect. Point is that is all under your control.

BTW, any reason why you use ODBC and not SqlClient?

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