My program creates databases and tables at runtime. My understanding of Schema is it is a conceptual folder for multiple databases and databases tables. So I wrote some meaningless code just to test out what schema would do to my code.
My program use SQL Server Authentication instead of Windows Authentication, and create database and tables under the username of TmpUser instead of sa.
If I create a table by CREATE TABLE TmpTable, I get dbo.TmpTable for table name. If I explicitly type a new schema in CREATE TABLE abc.TmpTable, I then get the following exception because the schema does not exist:
SqlException: The specify schema name either does not exist or you do
not have permission to use it
I went into SSMS and manually create a schema by executing CREATE SCHEMA abc. SSMS outputs saying the schema of abc has been successfully created. But in SSMS Object Explorer > Security > I see no Schema name nor anything else named abc.
Where is my Schema? If abc was not created, then why was CREATE SCHEMA abc executed and what did it create?
I went back to Visual Studio and CREATE TABLE abc.TmpTable again, still I receive the same exception.
Your TmpUser has no right to access the schema.
Option 1
CREATE SCHEMA abc AUTHORIZATION TmpUser;
Quoted from https://learn.microsoft.com/en-us/sql/t-sql/statements/create-schema-transact-sql:
"AUTHORIZATION owner_name
Specifies the name of the database-level principal that will own the schema. This principal may own other schemas, and may not use the current schema as its default schema."
TmpUser will own the schema, therefore will have permission to access it.
Option 2
Explicitly granting permission to the TmpUser:
GRANT SELECT, UPDATE, DELETE, INSERT SCHEMA abc TO TmpUser;
See usage on https://learn.microsoft.com/en-us/sql/t-sql/statements/grant-schema-permissions-transact-sql
It's like Option 1, but you can fine grain permissions.
Option 3
Put TmpUser to some database roles, e.g. db_datareader:
USE MyDatabase
GO
ALTER ROLE db_datareader ADD MEMBER TmpUser
TmpUser will have read access to all schemas in the database.
Option 4
It is similar to Option 3, but instead of using built-in roles, create your own one:
USE MyDatabase
GO
CREATE ROLE myrole
GRANT SELECT, DELETE, INSERT, UPDATE, EXECUTE TO myrole
ALTER ROLE myrole ADD MEMBER TmpUser
Users in myrole will have read/write/execute access to all schemas in the database.
Related
I would like to ask you if it is possible to proceed (in entity framework core):
context.Database.Migrate();
using database user without ddladmin permissions?
What I would like to achieve:
User without permission should not update migrations (without errors). However users with those kinds of permissions should be able to make migrations.
Currently, I am getting this kind of errors:
System.Private.CoreLib: Exception while executing function: xxx. Core
Microsoft SqlClient Data Provider: CREATE TABLE permission denied in
database 'xxxx'.
You have two options:
You give the user the db_ddladmin role
You add the create table grant to the user, like GRANT CREATE TABLE TO Joe AS dbo
I think the second one is what you are looking for.
I have a schema in MySQL '_users' which includes 1 table with two columns (username, telephone number). For simplicity lets assume that i have 4 store procedures.
SP_Find user: Return the user telephone number (Select)
SP_Add user: Add a new user and telephone number (Insert)
SP_Delete user: Remove user (Delete) - delete row
SP_Update user: Change the users telephone (Update)
I have one user in MySQL. In order for the C# connection to work i need to give to the user: 1) under the Administration Tab - Global Privileges - SELECT and 2) under the Schema Privileges - EXECUTE in '_users'.
When i try to remove the first one, the C# request to run any procedure is denied. I don't want to give 'Global Privileges - SELECT' to the c# app because ti will have access to Select through all schemas.
I would like to give access to my C# app only to run the stored procedures. How can i do this?
I'm trying to create new DB user for Firebird 2.5 DB from my C# application and geting an error "add record error no permission for insert/write access to TABLE USERS".
I've granted rdb$admin role to the user, created connection to DB using this role yet still i'm getting this error.
Wierdiest thing for me is that when i'm trying to create new user for my DB in IBExpert using same user settings and role (rdb$admin) it goes fine and I don't get eny errors.
What could be the problem? Why can't I execute SQL queries and procedures that update/insert in USERS table although I have appropriate role, that I'm using establishing connection?
I'm using latest FirebirdClient - ADO.NET Data Provider.
Connection string to the DB looks like this:
`"User=developer;Password=*****;Database=C:\DB.fdb;DataSource=*****;Port=*****;Dialect=3;Charset=NONE;Role=rdb$admin;Connection lifetime=15;Pooling=True;MinPoolSize=0;MaxPoolSize=50;Packet Size=8192;ServerType=0;"`
Can somebody help me with this problem?
I've found a solution - problem was that I forgot to GRANT ADMIN ROLE to the user by which I've executed procedure so I can't manage database users.
So GRANT ADMIN ROLE to user solved the problem.
I want to check if a database is working as a "Publisher" to other databases.
To do this I was planing on checking if the database "distribution" exists on that instance.
after reading this I thought I could just do
new Sqlcommand("SELECT name FROM master.dbo.sysdatabases WHERE name = #name")
and solve my problem...but I dont have that table in my database...:s
is there another way to solve my problem?
If you want to know if a database is a publisher then looking for a distributor is the wrong check. A database can have a remote distributor, in which case you'll get a false negative. Or the distributor may exist but the database may not be a publisher, in which case you get a false positive. Not to mention that the distribution DB may have any name, so looking for a database named distribution is also wrong.
The proper way to do it is to sue the built in replication helper procedures:
exec sp_helppublication will return information about all publications in a database. IF the database is not a publisher, it won't return anything (yoru cue to action).
exec sp_helpdistributor will return information about the distributor of a publisher
exec sp_helpdistributiondb will return information about a distribution database
In addition, the simple facts whether the DB is a publisher, subscriber or distributor can be discovered in sys.databases:
is_published Database is a publication database in a
transactional or snapshot replication topology.
is_merge_published Database is a publication database in a merge replication topology.
is_subscribed Database is a subscription database in a
replication topology.
is_distributor Database is the distribution
database for a replication topology.
Assuming you have sufficient permissions to view database metadata you can use
SELECT CASE
WHEN DB_ID('distribution') IS NULL THEN 0
ELSE 1
END AS distributionExists
select *
from sys.databases
where name = #name
Very close. It looks like that is SQL Server 2000 catalog view. What you are looking for is querying sys.databases.
I created a login to connect to SQL SERVER.
create login bobLogin with password = 'bobpass' , default_database = bobDB
but when i am connecting sql server using this, it does not connects? because it needs a user.
so i created a user:
create user bobDB_USER for login bobLogin
then i connected to sql server using bobLogin & tried to create table:
create table bobDbTable(eid int)
which gives permission denied error;
so i granted permission:
GRANT CREATE TABLE TO bobDB_USER
then i again connected using bobLogin, & tried to create a table but it gave error:
The specified schema name "dbo" either does not exist or you do not have permission to use it.
why so? its creating the table in the dbo schema, thats why? so how do i grant him this permission ?
i dont want to create a new schema. is it necessary?
You would need to GRANT ALTER ON SCHEMA::dbo TO bobDB_USER to allow objects to be created in the dbo schema.
I would also use a Role too.
create role bobDB_ROLE
EXEC sp_addrolemember 'bobDB_ROLE', 'bobDB_USER'
GRANT ALTER ON SCHEMA::dbo TO bobDB_ROLE
However, you could addbobDB_USER into db_owner if it requires these rights
EXEC sp_addrolemember 'db_owner', 'bobDB_USER'
Note: end user permissions are quite different to admin type rights. If 'bobDB_USER' is an end user, then they should not be creating objects