Problems Reading Scripts - XML

• 

  SQLGuru wrote:

  The new Problems Reading Scripts functionality is proving very helpful. In addition to helping me more quickly pinpoint the occasional syntax error checked-in by the devs, the report is pinpointing SQL Compare limitations. I've always had some procedures that SQL Compare could not parse -- it is beginning to look like they all have some things in common. Namely, procedures that include [WITH XMLNAMESPACES] and/or [FOR XML PATH]. However, it is only some procs with these keywords. I haven't isolated the commonality any further yet. Can you guys shed any light on this? Are you aware of specific XML syntax sequences that cause problems?

  
  Many thanks for reporting this. We will certainly look into this, but it would help us if you could send some of these stored procedures to me at Andras.Belokosztolszki at red-gate dot com
  
  Regards,
  Andras

  Andras B February 16, 2009 04:43

  - 0 +
• 
  I've had the same issue as well. Though the sprocs it can't parse for me don't have anything to do with xml. I'll pass some along to you and David Atkinson.

  jamal February 16, 2009 11:09

  - 0 +
• 

  jamal wrote:

  I've had the same issue as well. Though the sprocs it can't parse for me don't have anything to do with xml. I'll pass some along to you and David Atkinson.

  
  Hi James,
  we had a look at your scripts, and the primary problem is that it uses the "merge" word as a table alias. This is a keyword in SQL Server 2008 (but not in previous version). MS introduced this keyword, and it made it very difficult to parse older versions of SQL Server scripts. We have made a decision to keep and maintain a single parser, consequently this is a limitation we will not be able to resolve. The workaround I could suggest is to use [merge] instead, it brackets will escape the merge word. Alternatively, you should try to rewrite your statement, so that it does not use the merge word as a table alias. This will help you to migrate in the future to SQL Server 2008, as well as make sure your future sync scripts will execute (on a SQL Server 2008 database)
  Thanks for your help,
  Regards,
  Andras

  Andras B February 17, 2009 03:49

  - 0 +
• 
  Hi, thanks for the reply. Yes, that is quite an old file and on top of that it is from a third party product that we support. At least the initial solution of just escaping the keyword would not change the file too much, though we try to keep our customizations separated as a practice.

  jamal February 17, 2009 08:29

  - 0 +
• 
  I've emailed one of the procedures raising an error. I'll try to investigate a bit further later today.

  SQLGuru February 17, 2009 09:53

  - 0 +

Add comment

Please sign in to leave a comment.