System Objects - Redgate no longer ignores

mzcopeamzcopea Posts: 31
edited November 3, 2006 1:22PM in SQL Compare Previous Versions
A developer applied changes to ALL stored procedures under our development database, including the system stored procedures. Now when we use Red-gate to compare that database to production, Red-gate thinks the system stored procs are brand new objects that need to be created. Of course that fails because they already exist.

I assume that this is because the properties of the system stored procedures have changed. Even though the developer backed his changes out, Red-gate still wants to recreate these as new objects.

Is there any way to resolve this?



  • Options
    Brian DonahueBrian Donahue Posts: 6,590 Bronze 1

    Normally this would not happen, because SQL Compare ignores any objects marked as 'system'. What's more than likely happened is that when the system objects were modified by your user, they lost the 'system' bit and became 'user' objects. When that happened, SQL Compare tried to synchronize them because the destination database, as far as SQL Compare is concerned, doesn't hane these objects in it because they have been filtered out.

    This leaves you with two choices: Either de-select these objects in the SQL Compare comparison results, or find a way to repair that database by marking the MS-Shipped objects as 'system' type.

    Neither solution is particularly easy. In fact the second one may be the worst because there is no built-in stored procedure that will set the particular bitfield that marks an object as 'system'.
Sign In or Register to comment.