How do I create a SQL table under a different schema? - sql

This is from SQL Server 2008, ssms
When I create a table, it creates under dbo.
I would like to create it under a different schema, but when I use the 'New Table' dialog, I can never find the field where to specify this.

Right-click on the tables node and choose New Table...
With the table designer open, open the properties window (view -> Properties Window).
You can change the schema that the table will be made in by choosing a schema in the properties window.

Try running CREATE TABLE [schemaname].[tableName]; GO;
This assumes the schemaname exists in your database. Please use CREATE SCHEMA [schemaname] if you need to create a schema as well.
EDIT: updated to note SQL Server 11.03 requiring this be the only statement in the batch.

Hit F4 and you'll get what you are looking for.

create a database schema in SQL Server 2008
1. Navigate to Security > Schemas
2. Right click on Schemas and select New Schema
3. Complete the details in the General tab for the new schema. Like, the schema name is "MySchema" and the schema owner is "Admin".
4. Add users to the schema as required and set their permissions:
5. Add any extended properties (via the Extended Properties tab)
6. Click OK.
Add a Table to the New Schema "MySchema"
1. In Object Explorer, right click on the table name and select "Design":
2. Changing database schema for a table in SQL Server Management Studio
3. From Design view, press F4 to display the Properties window.
4. From the Properties window, change the schema to the desired schema:
5. Close Design View by right clicking the tab and selecting "Close":
6. Closing Design View
7. Click "OK" when prompted to save
8. Your table has now been transferred to the "MySchema" schema.
Refresh the Object Browser view To confirm the changes
Done

Shaun F's answer will not work if Schema doesn't exist in the DB. If anyone is looking for way to create schema then just execute following script to create schema.
create schema [schema_name]
CREATE TABLE [schema_name].[table_name](
...
) ON [PRIMARY]
While adding new table, go to table design mode and press F4 to open property Window and select the schema from dropdown. Default is dbo.
You can also change the schema of the current Table using Property window.
Refer:

When I create a table using SSMS 2008, I see 3 panes:
The column designer
Column properties
The table properties
In the table properties pane, there is a field: Schema which allows you to select the schema.

The default schema for the user could be changed with the following query and avoids changing the property every time a table is to be created.
USE [DBName]
GO
ALTER USER [YourUserName] WITH DEFAULT_SCHEMA = [YourSchema]
GO

Related

Why are tables created with default schema dbo although I specified a different schema?

If I run a sql script in SQL Server 2005 SSMS (Version 9.00.4035.00) like
CREATE TABLE xxx.MyTable
the table will be created as dbo.MyTable although the schema xxx does exist! No error message!
The user I'm using to run the script as all permissions (tested with windows user and sql user with server role sysadmin)
What's wrong?
You probably have 2 tables now
xxx.MyTable
dbo.MyTable
To check:
SELECT SCHEMA_NAME(schema_id), name, create_date, modify_date
FROM sys.objects
WHERE name = 'MyTable'
Don't rely on SSMS Object Explorer: it needs refreshed (right click on the tables node, refresh).
Or wrong database, wrong server etc.
We use schemas and never had any problems
Edit: now check all databases
EXEC sp_msforeachdb '
USE ?
SELECT SCHEMA_NAME(schema_id), name, create_date, modify_date
FROM sys.objects
WHERE name = ''MyTable''
'
Please take a look at the possible workarounds:
1) Create a SQL login with dbo rights to the database where tables and other objects have to be created. Have the users connect to SSMS using the SQL login that you have created. Tables can be created using SSMS without issues.
2) Have the user of windows security group create table using TSQL. You will see that a new schema and user will be created for this database with the user name of the user. Table gets created with windows user name as the owner .
Now, go to the database user which got created. Change the default schema to xxx.
User of that security group can create tables in SSMS and with dbo as the object owner.
Apparently, this is a microsoft bug and has not been resolved yet.
https://connect.microsoft.com/feedback/viewfeedback.aspx?FeedbackID=238246&wa=wsignin1.0&siteid=68
Hope this helps.

SQL Server - Permission on a per table basis?

I have a .net where I only have read access to the SQL Server database. Is it possible for SQL Server to give me write access to just ONE of the tables in the database, and restrict me to read only for the rest of the database?
Use this TSQL script, if you need:
EXEC sp_addrolemember N'db_datareader', N'User1';
GRANT INSERT, UPDATE, SELECT ON
MyTable
TO User1 --for multiples, it's TO User1,User2
In SQL Server Management Studio, right-click the read-only user in database name|security|Users and select Properties.
Select "Securables" and click "Search...". In the popup select "All objects of the type..." and click OK. Select "Tables" in the next window and click OK.
Then back in the Securables window, for each table that the user may write to:
Click on the table, and in the Permissions window underneath, in the "Grant" column, select "Insert", "Select" and "Update".
Yes, yes it is.
Just grant yourself the ReadOnly role and give yourself explicit write permissions to the table in question.

MS Sql Server table based user authorization

I want to restrict some MS Sql Server users. For example, one user should just be able to see 2 columns of "Customers" table and none other. And this user shouldn't be able to create any manipulation queries. But one user should be able to do everything on all tables and all columns. How do i do that?
BR,
Çağın
Create a view that only selects the two columns in question. Then remove the select, update and insert grants from the original table, and only grant the user select on the new view.
I find a way like this :
Click securables tab from user name on database's security.
Click search button and choose object type. (I need just tables)
Click Browse and choose table(s) and click OK
Choose Explicit and click Column Permissions
Choose Columns and click OK
it is working for my situation.
Use the datareaders role to restrict write access, and use a view to hide columns. Remove the the select right on the table to prevent a query directly on it.

Create Schema in SSMS

I am installing an application that requires me to set up a SQL Server DB with a schema. According to the SSMS 2008 documentation, after creating the DB I can expand the DB in the tree then right click on Security and I should have an option New Schema but I only have New User, Database Role.. and Application Role..
I tried just doing it with T-SQL:
use myDB;
create schema mySchema authorization db_owner
The command succeeded so I would expect after this that if I create a table, the Schema drop down list should include mySchema as an option but it doesn't.
Any ideas?
You need to refresh it. Highlight the Schemas folder and press F5.

Unable to create a simple view on Oracle table

An external DB admin guy exported a production database and imported it into test environment. We are using Oracle 9.2. Majority of imported database objects (tables, views, idexes, packages,...) works fine, but we have problems with three specific tables: we can do SELECT,UPDATE, DELETE on those tables, but we can not create views on this tables.
In other words, the folowing works:
create or replace view v_test_view as select 1 x from dual; // we can create views
create or replace view v_test_view as select 1 x from someTable;
select * from problematicTable; // we can select data from problematic table
But this does NOT work:
create or replace view v_test_view as select 1 x from problematicTable;
--> ORA-01031: insufficient privileges
Background info:
db admin used import/export utility to copy the database schema
the version of production and test Oracle are not exactly the same (production is 9.2.0.8, test is 9.2.0.7)
after the initial import was done, the problematicTable was visible in object catalog (and database development tools), but when trying to SELECT from this table, we got back "invalid identifier". After that, the tables were re-imported and now we are able to SELECT from the, but not to create views on them
Any ideas?
UPDATE:
It looks like the situation is even more strange. When using one oracle session we can SELECT data from this table, in another Oracle session (using the same user to login!), we are getting "ORA-00904: invalid identifier"
UPDATE#2:
The export data that was used to import from was sucesfully used to import data to another test environment (lets call it TEST1) which is located on the same instace of Oracle as the problematic one (TEST2). The difference beteween those two environments are that TEST1 uses the same user (schema name) as the production, but TEST2 uses another user (soo the objects were imported into another schema name). The problematicTables do not have any special security properties that are different from the tables that works OK.
Matra
Is the user creating the view granted select on the problematic table via a ROLE? If so, try giving an explicit grant on the table.
From Oracle:
"In order to create a view in a schema, that schema must have the privileges necessary to either select, insert, update, or delete rows from all the tables or views on which the view is based. The view owner must be granted these privileges directly, rather than through a role. The reason is that privileges granted to roles cannot be inherited via objects."
It looks like there was something wrong with the import. So what our DB admin did to fix the problem was:
drop the problematic tables
reimport the structure of the problematic tables (columns, constraints, indexes)
after the structure was re-created he re-imported the data
he also played with the CREATE TABLE AS SELECT to copy the data back and forth
When he was re-creating the table structure he discovered, that the current schema run out of free space (it was not set to auto grow). The strange thing is, that the first import did not complain about insufficient space.
So in theory is that insufficeint space was the reason for corrupted data dictionary.