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

Forum for users of SQL Compare schema synchronization utility

Moderators: JonathanWatts, Chris Auckland, David Atkinson

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

Postby andreas_agren » Wed Feb 22, 2012 2:55 pm

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: Select all
-- 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?
andreas_agren
 
Posts: 9
Joined: Wed May 25, 2011 7:53 am

Postby james.billings » Mon Feb 27, 2012 4:22 pm

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).
james.billings
 
Posts: 1144
Joined: Wed Jun 16, 2010 11:10 am
Location: My desk.

Postby andreas_agren » Mon Feb 27, 2012 10:01 pm

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.
andreas_agren
 
Posts: 9
Joined: Wed May 25, 2011 7:53 am


Return to SQL Compare Previous Versions

Who is online

Users browsing this forum: No registered users and 0 guests