Build Server Debugging

Early in June, I posted about inheriting a continuous integration setup from a former colleague.  Since then, I’ve replaced CruiseControl.NET and MSTest with TeamCity and NUnit 2.5.1, added FxCop, NCover, and documentation generation (with Doxygen).  This system had been running pretty smoothly, with the exception of an occasional build failure due to SQL execution error.  Initially, I thought the problem was due to the build restoring a database for use by some of our integration tests.  But when replacing the restore command with a script for database creation didn’t fix the problem, I had to look deeper.

A look at the error logs for SQL Server Express 2005 revealed a number of messages that looked like:

SQL Server has encountered <x> occurrence(s) of cachestore flush …

Most of what I found in my initial searches indicated that these could be ignored.  But a bit more googling brought me to this thread of an MSDN SQL Server database forum.  The answer by Tom Huleatt that recommended turning off the Auto-Close property seemed the most appropriate.  After checking in database script changes that included the following:



none of the builds have failed due to SQL execution errors.  We’ll see if these results continue.