Bug in rollback scripts,

ligtornligtorn Posts: 12 Bronze 2
edited August 5, 2015 11:14AM in SQL Compare Previous Versions
It seems that you cannot handled cases with roles, being owned by a user.

Repro

Create 2 empty database, Test1 and Test2

execute the script below on Test1. Do a Sql Comparsion between Test1 and Test2. select both the user and role, and synchronize Test2 into Test1, meaning the user and role should be dropped. However it will fail with "The database principal owns a database role and cannot be dropped".
Apparently this do work, if the role is owned by dbo

/Michael Søndergaard

/*
Run this script on:

DEVDB22-S1.SYS.DOM\DEV01.Dummy2 - This database will be modified

to synchronize it with:

DEVDB22-S1.SYS.DOM\DEV01.Dummy

You are recommended to back up your database before running this script

Script created by SQL Compare version 10.7.0 from Red Gate Software Ltd at 13-05-2014 16:15:37

*/
SET NUMERIC_ROUNDABORT OFF
GO
SET ANSI_PADDING, ANSI_WARNINGS, CONCAT_NULL_YIELDS_NULL, ARITHABORT, QUOTED_IDENTIFIER, ANSI_NULLS ON
GO
IF EXISTS (SELECT * FROM tempdb..sysobjects WHERE id=OBJECT_ID('tempdb..#tmpErrors')) DROP TABLE #tmpErrors
GO
CREATE TABLE #tmpErrors (Error int)
GO
SET XACT_ABORT ON
GO
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
GO
CREATE USER [TestUser] WITHOUT LOGIN
GO
PRINT N'Creating role TestRole'
GO
CREATE ROLE [TestRole]
AUTHORIZATION [TestUser]
GO
BEGIN TRANSACTION
GO
IF EXISTS (SELECT * FROM #tmpErrors) ROLLBACK TRANSACTION
GO
@TRANCOUNT>0 BEGIN
PRINT 'The database update succeeded'
COMMIT TRANSACTION
END
ELSE PRINT 'The database update failed'
GO
DROP TABLE #tmpErrors
GO

Comments

  • Hi Michael,

    It looks like this is caused by the way SQL Compare scripts out the changes - if you have a look at the deployment script, you'll see that it attempts to drop the role first, which is what causes the problem. You can work around it in one of two ways:

    1. Run two separate deployments with SQL Compare, first dropping the user and then the role
    2. Get SQL Compare to generate a deployment script and manually edit it to drop the user before the role

    I suspect there's an underlying reason that we don't correctly deal with user dependencies like this, but I'm chasing up the SQL Compare team to see if there's a way we can deal with it better. Hope that helps!
    Andy Campbell Smith

    Red Gate Technical Support Engineer
  • ligtornligtorn Posts: 12 Bronze 2
    I came to the same conclusion. It must be because it's not respecting the dependencies correctly. I solve my problem with the same solution as you described, but I of cause still like to get it fixed, as it will give me issues in the future also

    /Michael
  • Hi Michael,

    Thanks for your patience!

    I am very pleased to tell you that we have fixed the issue SC-7222 you reported with SQL Compare:

    Link to release notes: http://documentation.red-gate.com/displ ... ease+notes
    Here is the direct link to the installer: ftp://support.red-gate.com/patches/SQLC ... 2.7.13.zip

    Please let me know if this solves the issue you are having.
    Anuradha Deshpande
    Product Support
    Redgate Software Ltd.
    E-mail: [email protected]
Sign In or Register to comment.