This post originated from an RSS feed registered with .NET Buzz by Robert Hurlbut. Original Post: Enterprise Services and TDD part 2 Feed Title: Robert Hurlbut's .Net Blog Feed URL: http://www.asp.net/err404.htm?aspxerrorpath=/rhurlbut/Rss.aspx Feed Description: Development with .Net, Rotor, Distributed Architectures, Security, Extreme Programming, and Databases Latest .NET Buzz Posts Latest .NET Buzz Posts by Robert Hurlbut Latest Posts From Robert Hurlbut's .Net Blog

I mentioned yesterday a special case of Roy's excellent article on using Enterprise Services with database unit testing where it seems to produce an inconsistent result with NUnit. The case involves a Server Application (I didn't try a Library Application for my test), Oracle, and NUnit. The issue is I can test successfully every other time, with a RollBack at the end of each transaction in order to put the database back to its original state. It's the every other time after that fails with these messages:

ORA-03113: end-of-file on communication channel

and

System.Runtime.InteropServices.COMException : You made a method call on a COM+ component that has a transaction that has already aborted or in the process of aborting.

Has anyone seen a solution to these problems? In our case, the way we solved this ultimately was to do the standard way of testing database layer code by either rebuilding the data schema over again (getting the data into a consistent state) or writing the tests in such a way as not needing to do a RollBack.  For unique constraint tests, I would use a GUID appended to a value.

As far as I can tell, Roy's usage of NUnit and Enterprise Services works perfectly with SQL Server, and I see it as a great solution. I think the issues I see with Oracle have to do with some missing or wrongly configured Oracle/MSDTC settings rather than flaws in Roy's approach. If anyone has a clue about the Oracle messages above, it would be greatly appreciated, as well as possibly helping someone else.

Update: If memory serves me correctly, I think we also determined at the time this oddity was related to an existing bug in v. 1.1 code with the System.Data.OracleClient namespace. A bug fix was available, but only if it was a major problem (not publically available). I can test in Whidbey code to determine if this issues is now resolved.