Error: If statement in fileD:\\build\\Database\\Security\\Users\\BUILTIN_Administrators.sql at line1 considered as trueError: The scripts folder at D:\\build\\Database contains parsererrors. Please review the scripts. You can ignore the parser errors by using the/ignoreparsererrors switch.

The hard part is that I can't reliably reproduce the error. If I run the exact same build a second time, it will work. The error doesn't always occur on the same file, though it's always on a user file. These user files haven't changed at all since we added them to Subversion. The error doesn't always occur at the same step in the build process, and it doesn't always happen on the same database. Usually the error comes from Data Compare, but sometimes it comes from SQL Compare. I've never been able to reproduce the error by running the same comparison through a command prompt. The error doesn't occur with any of our other build jobs.

The only thing that seems reliable is that it appears to happen every other time I run this particular build. I've examined the scripts following an error, and ran the comparison manually, but can't seem to figure out what causes it.

Thanks for your post, and I'm sorry you're encountering some trouble. From what you've described, it does sound a little strange. A parsing error usually occurs when the syntax in the file being read cannot be correctly interpreted by the product. However if this was the case, I would expect the problem to persist when you run it manually.

So, this leads me to a couple of thoughts- either the file is changing between the problem occurring and the subsequent run where it succeeds, or some other problem is occurring with the file that ends up being output as a parsing error.

For the former - are any developers running procedures that would be potentially updating the files during the run of Compare? For the latter, i'd suggest making sure that any antivirus scanners you have are excluding the folders where the scripts are located. We've seen this occasionally cause trouble with other applications (although I'm not sure it's popped out as a parser error) but it's worth checking.

Hi, thanks for the suggestions. My first thought was that the file is changing too. This is our automated build server, so nobody uses the machine but me. However I thought maybe part of the build process was changing the scripts, so I monitored the file during the build to see if it changed. It did not; in fact, the file's modified date is from months ago.

I had our IT team add the scripts folder to the antivirus exception list, but unfortunately, that didn't solve the problem either.

My earlier statement about this failing every other time is also no longer true; we had three consecutive successful runs last week, and two consecutive failures yesterday.

Please let me know if you have any other suggestions, or if there is more information I can gather to help. Thanks.

Hmm, as an intermittent problem it's a tricky one, especially as the file isn't actually changing by the sounds of it.

Ideally, we'd need the commandline to be able to output more detailed logging information that may help. Right now, it doesn't do that (although we do have a feature request, SC-4336 to look at this).

The only other thing I could think of, if you're performing a relatively simple sync, would be to knock up a quick app using our SDK to do it - in theory, when the exception occurs, you could then grab the full exception tree + stack trace which /may/ produce more information (although I won't guarantee it...)

Hi, I apologize for the late reply. We are now seeing this error on different servers and with different deployment scripts; it seems to be occurring with increasing frequency. It is still not reliably reproducible though.

Unfortunately, I've been moved to a new project so I don't have time to write an app using the SDK. If there is a simpler option or workaround then I could probably get some time to look into it.

One thought I had: we don't need to sync our users, they don't change frequently. Would it be possible to remove them from source control entirely? I'm concerned that it might cause dependency issues, but if there's a safe way to remove those scripts then I'm willing to try it.

You should be able to add filters in 2.2 to exclude users. To do this, right click the DB, select Other SQL Source Control Tasks > Edit Filter Rules.
You can then exclude users by unticking them - hopefully this may help?