Red Gate forums :: View topic - SQL Compare tries to create a not vc'ed user as a schema.
Return to www.red-gate.com RSS Feed Available

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

SQL Compare tries to create a not vc'ed user as a schema.

Search in SQL Compare Previous Versions forum
Post new topic   Reply to topic
Jump to:  
Author Message
andreas_agren



Joined: 25 May 2011
Posts: 9

PostPosted: Wed Feb 22, 2012 2:55 pm    Post subject: SQL Compare tries to create a not vc'ed user as a schema. Reply with quote

I have encountered a relly weird problem with a user that SQL Compare tries to script as a schema.

Here's how to reproduce the issue:

  1. Link a db to svn using red gate source control.
  2. Create a new user (e.g. test_user) and add it to the db_owner role for the vc'ed db.
  3. Commit the role change for db_owner but leave the user.
  4. Right-click the db and choose schema compare/deploy and set the db as both source and target. (I know it doesn't make sense to deploy to the same db but bear with me, it's just for the sake of reproducing the problem.)
  5. Change source to source to source control and pick the revision where you just commited a role change.
  6. Launch sql compare and click ok to do the comparison.


There will now be the following statement in the comparison window:
Code:
-- Schema

CREATE SCHEMA [test_user]
AUTHORIZATION [test_user]
GO


This user can also be seen as unmapped in the owner mapping window.

The only way to get rid of the create-schema-statement, afaik, is to also commit the actual user and then redo the comparison.

Am i missing something here or is this a bug?
Back to top
View user's profile Send private message
james.billings



Joined: 16 Jun 2010
Posts: 1144
Location: My desk.

PostPosted: Mon Feb 27, 2012 4:22 pm    Post subject: Reply with quote

Thanks for your post - I tried following your steps but got a different result; with my comparison results showing it wanting to drop the user from the target - this makes sense as the user wasn't committed, so doesn't exist in the source control version.
I'm not quite sure how you got it to display the result you saw, unless it's a function of the comparison options you selected.

Either way, we don't generally recommend you perform a "partial commit" like this, as it can lead to the Get Latest process not working for other users (think of the scenario where you create a new procedure and table, then commit just the procedure. When another user tries to do a "get" it'll fail as the dependent table doesn't exist).
Back to top
View user's profile Send private message
andreas_agren



Joined: 25 May 2011
Posts: 9

PostPosted: Mon Feb 27, 2012 10:01 pm    Post subject: Reply with quote

Your result sounds more like something I would expect. Maybe it's a problem with how I tried to reproduce the problem. You could, instead of releasing to the same database, release it to another database that is identical except for this change (i.e. before you added the user). In my case this would be checking in from the dev env, svn merge to test env, and release to the database there.
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