SQL Clone
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Schema name, Schema Owner and Login


Schema name, Schema Owner and Login

Author
Message
sqlenthu 89358
sqlenthu 89358
SSCommitted
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1892 Visits: 344
Hi guys,
I have two logins abc_prod and abc_dev in my prod environment. All our objects are created with schema abc. Now we are planning to remove abc_dev login from prod environment. However the schema abc has schema owner as abc_dev.

So my question is removing abc_dev will cause issues in accessing objects ? If yes, then should I first change the ownership of schema abc from abc_dev to abc_prod ?
Erland Sommarskog
Erland Sommarskog
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19510 Visits: 883
If you only want to drop the *login* which is on server level, there is no issue with the schema.

However, if you also want to drop the database *user*, then you must change the owner of the schema. Else SQL Server will not let you drop the user.

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
Adi Cohn
Adi Cohn
One Orange Chip
One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)One Orange Chip (28K reputation)

Group: General Forum Members
Points: 28258 Visits: 6653
Removing a user that owns an object from a database is impossible, so if you want to remove this user from the database, you'll have to change the schema's owner to another user. You can do that with this command:

ALTER AUTHORIZATION ON SCHEMA::WriteSchmeNameHere TO WriteNewOwnerHere



After modifying the owner there you can drop the user and there should be no problems at all accessing the objects on that schema.

Adi

--------------------------------------------------------------
To know how to ask questions and increase the chances of getting asnwers:
http://www.sqlservercentral.com/articles/Best+Practices/61537/

For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
sqlenthu 89358
sqlenthu 89358
SSCommitted
SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)SSCommitted (1.9K reputation)

Group: General Forum Members
Points: 1892 Visits: 344
Thanks for clarifying that thing guys. Appreciate.

One more question now. So I should change the ownership or my db schema from abc_dev to abc_prod. So whenever i'll refresh my lower environment there also it'll show the schema owner as abc_prod. Should there be any standard for it in industry. I guess I am freaking out just because of the naming convention (_prod given to the user) I guess. Am I right ?
Erland Sommarskog
Erland Sommarskog
SSCoach
SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)SSCoach (19K reputation)

Group: General Forum Members
Points: 19510 Visits: 883
I think I need to abstain from answering on what you should do. There is just too little I know about your situation.

I can add two tidbits though:

1) I would believe that the by far most common arrangement is that all objects are in the dbo schema owned by dbo. And even when people use multiple schemas, all schemas are typically owned by dbo. Thus, having all objects in a non-dbo schema owned by a non-dbo user is uncommon, why it is difficult to talk about standards.

2) As for the name, in the system I work with, we have a very simplistic security model on SQL Server level. We grant EXEC on all stored procedures and SELECT on all tables to a single role. The name of that role, be it production, test or development is "dvp". It is just that - a name. (In case anyone wonders, the application has it's own security model, which controls which UI functions users can access and what they can do in the functions.)

Erland Sommarskog, SQL Server MVP, www.sommarskog.se
sqlm0j0e
sqlm0j0e
Old Hand
Old Hand (386 reputation)Old Hand (386 reputation)Old Hand (386 reputation)Old Hand (386 reputation)Old Hand (386 reputation)Old Hand (386 reputation)Old Hand (386 reputation)Old Hand (386 reputation)

Group: General Forum Members
Points: 386 Visits: 104
Adding to Erland's tidbits:

3) Having a meaningful name for the owner is useful in some environments. In the simple scenario, a single name like Erland's works great. You always know what that role is used for. In your case, it sounds like you might have a requirement to isolate dev, test and prod access controls so having a prefix or postfix indicating dev, test or prod accomplishes the same goal: you always know what that role is for. I would not do it for the user though. If you grant access via roles then the same person will connect with the same login and user IDs but will have the appropriate permissions based on the role he's in. No need to remember 3 IDs plus you're creating management grief for yourself and user confusion by attaching dev, test or prod to logins or user names.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum








































































































































































SQLServerCentral


Search