Robert Hurlbut's Blog

Thoughts on .NET, Security, Architecture, Agility, and Databases.

Syndication

.Company / Other Sites / Other Blogs

.NET Links

.NET Local Boston Events

.NET User Groups in New England

Blogs - .NET

Blogs - Agile

Blogs - Architecture

Blogs - CLR

Blogs - Security

Blogs - SQL Server

Blogs - System.Transactions

Enterprise Services (COM+) Resources

Indigo Resources

Microsoft Security Resources

Presentation resources

Recommended Books

Rotor Resources

Security Resources

Enterprise Services and TDD part 2

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.

Published Tuesday, June 22, 2004 5:34 AM by RHurlbut

Comments

No Comments