false error message: scripts folder contains parser errors

vincentjvincentj Posts: 47
edited November 5, 2015 7:37AM in SQL Data Compare Previous Versions
Hi, I've been seeing errors reported by our build system that I haven't been able to figure out. Here's a sample error message:
Error: If statement in file
D:\build\Database\Security\Users\BUILTIN_Administrators.sql at line
1 considered as true
Error: The scripts folder at D:\build\Database contains parser
errors. 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.

I'm totally baffled by this. Any suggestions?


  • James BJames B Posts: 1,124 Silver 4
    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.

    Failing that, we'll have to see if we can get any more diagnostics...
    Systems Software Engineer

    Redgate Software

  • 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.
  • James BJames B Posts: 1,124 Silver 4
    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...)
    Systems Software Engineer

    Redgate Software

  • 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?
    Systems Software Engineer

    Redgate Software

  • I just verified, yes, we are already excluding users in all our filters. It seems that all the scripts get parsed even if they're excluded by a filter?

    (These errors are coming from SQL Compare/SQL Data Compare, not SQL Source Control, by the way. I double-checked to make sure they're both at the latest version, just to be sure.)
  • James is on holiday this week, so he's asked me to take a look at this.

    Would you be able to send a SQL Compare snapshot, or a backup of the database we can look at? If we could set up a similar project we could see if we find the same issue.

    If you are able to provide the schema, could you contact [email protected] and we'll open a ticket.


    Chris Auckland
  • Hi
    I'm getting this too - also random.
  • Hi,

    I talked to my manager, and we're not comfortable sending a database snapshot, sorry. Is there anything else we can try from here?
  • Still happening in latest version
    If found that the role has a impact on this using db_owner worked for me.
Sign In or Register to comment.