Schema name, Schema Owner and Login

Question

Schema name, Schema Owner and Login

sqlenthu 89358

Hall of Fame

Points: 3069
More actions
December 1, 2016 at 4:02 am

#401143

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 ?
June 14, 2017 at 9:14 pm

This was removed by the editor as SPAM

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply

Erland Sommarskog SSC-Insane Points: 24038 More actions · Answer 1

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.

[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

Adi Cohn-120898 SSC-Dedicated Points: 33944 More actions · Answer 2

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 Hall of Fame Points: 3069 More actions · Answer 3

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 SSC-Insane Points: 24038 More actions · Answer 4

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.)

[font="Times New Roman"]Erland Sommarskog, SQL Server MVP, www.sommarskog.se[/font]

sqlm0j0e SSC-Addicted Points: 450 More actions · Answer 5

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.