Change EF Core Migrations to different default owner - sql-server

I am creating a new .NET Core 3.1.3 application, connecting to a new SQL Server 2016 database. The connection is a trusted connection. The EF migration tool is creating the tables with me as the owner.
dotnet ef migrations add InitialDb
dotnet ef database update
I don't want that. I want the tables to be owned by a service id that we have created for the purpose. What is the safest and most efficient way to default table creation to that owner?

If you don't specify a schema for your Entities, EF will generate the DDL with no schema specified. And in SQL Server this means that the object will be created in the user's default schema. Normally the user's default schema should be dbo, but if it's not, then the object will be created in a different schema.
And in SQL Server objects are owned (again by default) by the owner of the schema in which they are created.
So, configure the tables to be created in the dbo schema, or configure your user's default schema to be dbo, and the objects will be created in the dbo schema and owned by dbo.
eg in OnModelCreating, add
foreach (var et in modelBuilder.Model.GetEntityTypes())
{
et.SetSchema("dbo");
}
or in SQL
alter user [yourdomain\youruser] with default_schema=dbo
Note that if you are the database owner, or a sysadmin, you always connect to the database as dbo, and your unqualified DDL will create objects in the dbo schema.
I want the tables to be owned by a service id
You don't normally want objects owned by the identity that the application uses to connect, as that identity should be in a role with least-privileges. EG no ability to drop tables or create triggers. Typically the objects should simply be owned by dbo.

At least as of EF Core 6 you can be more succinct with
modelBuilder.HasDefaultSchema("dbo");
Note that if you are using the built-in history table you will need to place extra code in the onConfiguring. Something like
optionsBuilder.UseSqlServer(x => x.MigrationsHistoryTable("__EFMigrationsHistory", "dbo"));

Related

DACPAC SQL Server dropping schema permissions

I am trying to use a DACPAC database project in Azure Data Studio.
So far, it works fine except for the "publishing" of the project to the actual DB.
When I generate the delta script, I see that all permissions on all schemas are being dropped.
I know that I could exclude certain objects:
SQL Server DACPAC Deployment Dropping Users/Roles/Permissions
However, I would prefer to have also the permissions of DB roles on a schema in the DB project.
Here, of course, the order is important. (Create schema, create user, create DB role, add user to DB role, grant permission for DB role on schema)
How (and to which file) can I add the schema permissions to the project and how can it be ensured that the TSQL statements that are generated are executed in the correct oder?
Thx.
At the linked QA have a look at the XML: there are separate parameters
DropPermissionsNotInSource
DropRoleMembersNotInSource
represented in sqlproj/publish.xml in a reversed way
<DoNotDropRoleMembership>True</DoNotDropRoleMembership>
<DoNotDropPermissions>True</DoNotDropPermissions>
By switching them to "do not drop" state you can avoid excluding permissions from deployment. Thus new permissions (defined in project but missing on target server) would be created but old ones (existing on target server but missing in the project) will not be dropped. Same goes for role membership.
Valid command order in publish script is guaranteed by the SSDT engine.
Still, permissions on target server can be lost if publishing requires object recreation. For example if you alter table-type then referencing procs will be dropped and recreated after type recreation.

How to create a local schema in Oracle database 11g?

I have installed Oracle Database 11g Release 2 (11.2.0.1.0) for Microsoft Windows (x64). How do I create a new schema or local schema?
A schema is the collection of objects owned by a user.
So connect as a power user like SYSTEM and run a create user command. Find out more.
Once you have a user you can connect to it and create tables and other objects.
Have you tried looking in the docs? https://docs.oracle.com/cd/E11882_01/server.112/e41084/statements_6014.htm#SQLRF01313
In oracle a 'schema' is nothing more than the collection of objects belonging to a given user. Many people will even argue that a "user" is a "schema". I believe that it was with 11g (now out of support) that oracle introduced the CREATE SCHEMA command. That command simply combines creating a user and creating some tables belonging to that user into a single SQL statement. You can always do it the "old fashioned" way by simply issuing a CREATE USER, then issuing whatever CREATE . statements you need:
create user fubar identified by fubar;
create table fubar.mytable (dob date);
create view fubar.myview as (select * from fubar.mytable);
etc. etc.

how to make Simple Membership create tables with default dbo schema

I have an issue with Simple Membership with SQL server using Entity framework code first.
When I run
WebSecurity.InitializeDatabaseConnection( "MyDB", "Users",
"UserID", "Username", true);
on my own development pc, It creates the following tables
dbo.Users
dbo.webpages_Membership
dbo.webpages_Roles
dbo.webpages_UsersInRoles
But, when I run the site on a host it creates the tables as:
myusername.Users
myusername.webpages_Membership
myusername.webpages_Roles
myusername.webpages_UsersInRoles
Please,
how do I get the simple membership provider to create the tables with the default dbo schema?
You can find here a good way to do this without specify a default schema for your user.
You just need to follow this implementation and define the default schema.
Like this:
[Table("webpages_Membership", Schema = "SCHEMA_NAME")]
WebSecurity.InitializeDatabaseConnection uses the default schema
assigned to your Database User to create\access the tables
for the SimpleMembershipProvider.
So you need to change the default schema your user has on the Database on your host.
Does your host allow you to set the default schema for your Database User?

Default role mapping when creating a MSSQL Server database

Is it possible to set up a default set of role mappings for Microsoft SQL Server (2008 R2 for instance) that apply to subsequent databases?
Example: Whenever I create a new database on the server, I want it to map db_owner to a login group called Group_A and db_datareader to a group called Group_B.
The databases are created by a 3rd party application, so doing it in the CREATE statement is not enough. What I hope for is to set a default behaviour for the server itself.
Every new database is created as a copy of the model database on the SQL server. So when you do the mapping the the MODEL db every new DB should replicate that. I haven't tried that with roles and groups but you can try it and let me know whether it works...

SQL Server 2005 - Create Database with permissions for another database

I am a complete SQL Server newbie but I have experience with Oracle and MySQL. I am using SQL Server Management Studio.
I have an existing database that I want to create views from but I want those views to reside in another database (schema?) which will be accessible by a separate user account that can connect via JDBC.
I can create the database easily enough, right click "Databases" and select "New Database". From there I am lost.
1) How do I grant select/update/delete permissions (to create and update views) on one database to the new database?
2) How do I create a new user?
3) How do I grant permissions for users?
Thanks in advance.
Like Martin said you need a new schema not a database.
CREATE SCHEMA [SchemaName] AUTHORIZATION dbo;
Create your Views under the new schema name then,
CREATE LOGIN [LoginName] {FROM WINDOWS} (If you are using an AD Group)
USE [DatabaseName];
CREATE USER [LoginName/Username]; (They can be the same)
GRANT EXECUTE, SELECT, INSERT, DELETE, VIEW DEFINITION ON Schema::[NewSchemaName] TO [LoginName/Username];
If you want to have a Role the create the role under the database and make the UserName a member of the Role and grant the permissions to the role.

Resources