Last week I was tasked with changing our build script from using sql scripts to build the database, to running sql scripts to backup and restore a "gold standard" database. Aside from a few permission issues, things went mostly well. However, in the process I updated MSBuild Community Tasks to the nightly build version. I had an error I thought it might help with, but it turned out not to be the case. I kept the unreleased version in production because it generated clearer messages in the ExecuteDDL task. For those of you that don't know, version 1.2.0.306 gives truly awful information in the event a sql script fails.

Fast forward to tonight. I had to roll out a demonstration version of the software from the previous iteration. This meant changing views in the source control system so it would execute the previous versions scripts. When I ran it, received this error (traceable info changed): C:\MyData\Project\base\src\Project.proj (1550,3):  error : ProjectCDDB: Error # -2 on Line 0: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding.

I used the ultracool "MSBuild Output" report to get color coding so I could easily trace down which file was causing the error. I then looked at it's size. Sure enough, it was a beast. But it used to run, and it worked when I manually executed it, so what was different? MSBuild Community Tasks, of course.

I pulled down the latest source and opened up ExecuteDDL. Sure enough, there was a new property in the class... StatementTimeout, defaulted to 30 seconds. That's probably not the best timeout for a sql script that exceeds 5 megabytes.

I changed the timeout to 120 seconds; yet another problem solved. I suppose this sort of thing is bound to happen when you're changing version of libraries and then forced to use chronomancy to pretend it's a month in the past.