1

わかりました、それらは単体テストではなく、エンドツーエンドのテストです。セットアップは多少複雑です。ユニットテストでは、C#、ODBC接続を使用します。すべての単体テストはそれ自体の後でクリーンアップを試みますが、20回程度のテスト(C#クラスごとに1回)ごとに、データベースの完全な復元を実行する必要があります。このドキュメントによると、ODBC接続を介してそれを行うことはできないと思います。

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

メッセージ6104、レベル16、状態1、行1KILLを使用して独自のプロセスを強制終了することはできません。

ただし、クリーンアップが不十分なために199のテストが失敗しないようにしたいと思います。別の方法はありますか?おそらく、COM自動化などの別の「接続」を開いて、そこからすべてのデータベース接続を強制終了することができますか?もしそうなら、どうすればそれを行うことができますか?

また、クライアントは復元後に自動的に再接続できますか、それとも20回程度のテストごとにすべてを解体する必要がありますか?

この質問がわかりにくい場合は、質問を教えてください。ありがとう!

4

2 に答える 2

1

ODBC 接続を適切に閉じることができることを確認できれば、C# 統合テストのために、ADO.NET を直接使用して、プールからの新しい接続で復元を実行できます。

完全バックアップではなくスナップショットからの復元に切り替えると、はるかに高速になると思います。

于 2011-01-06T21:53:11.377 に答える
1

もちろん、ODBC 接続から復元できます。復元しようとしているデータベースを使用している場合は復元できませんが、コンテキストをtempdbまたはに変更するのは簡単masterです:

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

データベースを使用する他の接続がある場合、それらは独自の接続になるため、適切に閉じていることを確認するだけの問題です。接続プーリングを使用する場合は、プールを消去します。SqlClientを使用しますがSqlConnectionClearAllPools、ODBC はOdbcConnection.ReleaseObjectPoolを使用して同様の効果をもたらします。ポイントは、それはすべてあなたの管理下にあるということです。

ところで、SqlClient ではなく ODBC を使用する理由はありますか?

于 2011-01-06T21:54:08.267 に答える