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

andreas_agrenandreas_agren Posts: 14
edited February 27, 2012 4:01PM in SQL Compare Previous Versions
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: 
-- 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?
· Share on Twitter

Comments

  • James BJames B Posts: 1,124 Silver 4
    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).
    Systems Software Engineer

    Redgate Software

    · Share on Twitter
  • andreas_agrenandreas_agren Posts: 14
    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.
    · Share on Twitter
Sign In or Register to comment.