How to ignore [brackets]?

mfc2mfc2mfc2mfc2 Posts: 17 Bronze 2
edited November 22, 2010 9:07AM in SQL Compare Previous Versions
One of the most common differences I see is object names having brackets on one server and not the other. [dbo]. = dbo.table.
Ultimately I would like to know what keeps adding the brackets back, but until then maybe there is a way to have SQL Compare ignore these brackets when doing comparisons?

Does anyone know how to ignore brackets or what process keeps adding them back?

Thank you,
Mike Chabot

Comments

  • mfc2mfc2mfc2mfc2 Posts: 17 Bronze 2
    Another thing to equate would be defaults with an extra set of parenthesis. Sometimes I see DEFAULT (0) = DEFAULT ((0)). I'm not sure the root cause of the double parenthesis.
  • It's not actually SQL Compare putting them in, it's SQL Server. The behavior changed in SQL Server 2008 so usually it's an issue if you're comparing two different versions.

    Although the textual viewer identifies these as differences, the main object differences grid will not regard these as a real difference.

    David Atkinson
    Red Gate Software
    David Atkinson
    Product Manager
    Redgate Software
  • I see the project option new to Compare 8:
    Ignore square brackets in object names
    Ignore starting and ending square bracket in object names which have been escaped using square brackets. This applies to textual objects such as stored procedures, triggers, etc.
    This option allows me to ignore differences I was seeing with Compare 7 where the identifier for a server instance is delimited with square brackets in a query of a stored procedure in only one database being compared. For example, this difference will no longer cause a stored procedure to be considered different:

    select * from [dbserver1].dbo.Table1
    VS
    select * from dbserver1.dbo.Table1

    Unfortunately, it is still considered a difference when the delimiter appears in a string to be used in a dynamic query; e.g., the stored procedures containing the following statement will be considered to be different:

    set @SQL='select * from [dbserver1].dbo.Table1'; exec (@SQL)
    VS
    set @SQL='select * from dbserver1.dbo.Table1'; exec (@SQL)
  • mfc2mfc2mfc2mfc2 Posts: 17 Bronze 2
    Thanks for pointing that out. It looks like that new option was added in version 8.5, although it is not mentioned in the release notes.

    Thanks to redgate for adding that option.
  • Indeed, the option is not mentioned in the user documentation either.
Sign In or Register to comment.