Bug in rollback scripts,

Compares and synchronizes SQL Server databases, backups and scripts.

Moderators: JonathanWatts, Chris Auckland, David Atkinson, eddie davis, Anu Deshpande, Michelle Taylor, alice.easey, james.billings, chengvoon.tong

Bug in rollback scripts,

Postby ligtorn » Tue May 13, 2014 3:24 pm

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
IF @@TRANCOUNT>0 BEGIN
PRINT 'The database update succeeded'
COMMIT TRANSACTION
END
ELSE PRINT 'The database update failed'
GO
DROP TABLE #tmpErrors
GO
ligtorn
 
Posts: 8
Joined: Thu Jul 30, 2009 4:15 pm

Postby andy.campbell.smith » Thu May 15, 2014 4:57 pm

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
andy.campbell.smith
 
Posts: 173
Joined: Thu Oct 20, 2011 11:19 am
Location: Red Gate Software

Postby ligtorn » Wed May 21, 2014 10:29 am

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
ligtorn
 
Posts: 8
Joined: Thu Jul 30, 2009 4:15 pm


Return to SQL Compare 10

Who is online

Users browsing this forum: No registered users and 1 guest