Red Gate forums :: View topic - Bug in rollback scripts,
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Compare 10
SQL Compare 10 forum

Bug in rollback scripts,

Search in SQL Compare 10 forum
Post new topic   Reply to topic
Jump to:  
Author Message
ligtorn



Joined: 30 Jul 2009
Posts: 8

PostPosted: Tue May 13, 2014 3:24 pm    Post subject: Bug in rollback scripts, Reply with quote

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
Back to top
View user's profile Send private message
andy.campbell.smith



Joined: 20 Oct 2011
Posts: 173
Location: Red Gate Software

PostPosted: Thu May 15, 2014 4:57 pm    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
ligtorn



Joined: 30 Jul 2009
Posts: 8

PostPosted: Wed May 21, 2014 10:29 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group