I've been using LinqPad for a while now, but have only noticed this problem recently. We have some stored procedures in our DB that have a schema other than dbo, such as [admin].[ClearTransientData].
When I connect to that database with LinqPad, it will only show the stored procedures with the [dbo] schema.
The schema in question is owned by the dbo role and I'm connecting to the database with an account in the dbo role. When I connect to the same database with SSMS using the same account, I can see all of the sprocs no matter the schema.
Am I missing something in the connection definition?
I found the answer, thanks to a prompting from the mobile stackexchange app. I cannot find the user that contacted me (if it was you, please add a comment to the question above or post an answer so I can mark it correct).
Anyway, the default grouping in Linqpad is:
Schema
Tables (only nested in the default schema)
Functions
Stored Procs
Views
However, for the default schema (dbo in this case), that grouping is left out, so 'Tables', 'Functions', 'Stored Procs' and 'Views' appear at the top level. This led me to believe that all stored procedures would be grouped at the top 'Stored Procs' level, then sub-grouped by shcema name under that. This is not the case.
All I had to do was expand the 'Admin' schema[1] in the tree and there was the 'Stored Procs' grouping I was looking for.
Admin
Table1
Table2
Stored Procs
proc1
proc2
Thanks,
Mark
[1] the name of the schema in question actually begins with 'V', which placed deep in the tree view. Since I'm lazy and had to scroll down to see it, I didn't see it right away.
Related
I am using SQL Server 2017. I am in the role of sa for the server in question. I have two databases that are used in an ETL process. The ETL is coded in one database, and the raw imported tables are located in the staging database. All ETL is handled in SQL stored procedures that follow a pattern. The first step in each ETL SP is a call to a diagnostics table in the staging database.
My current ETL job is a wrapper around two of these ETL sps; the wrapper itself contains only code that accesses the main db.
The first SP can be called and successfully selects the data from the staging db, however, the second SP that has identical code up to the point of failure with the first, fails on accessing the diagnostics table and tells me
The server principal "sa" is not able to access the database "staging" under the current security context.
The problem stays if I comment out the first SP call, so something must be different in the definition of the two SPs, but I cannot spot it.
There are plenty of SPs that use the diagnostics staging table, so it is not a general problem (as stated in answers to similar questions that suggest changing security options in the staging database), but must be related to the new SP somehow.
Any suggestions?
There are three things to check/do.
First of all, the login associated with the user in database DB1 must also be associated with a user in DB2. This provides the login with a security context in database DB2. The sa login will map to dbo in both databases, so this should already be fine.
Second, the security context of the code being executed in DB1 must be "trustworthy". In other words, when the user context goes from DB1 back up to the server level and then down into DB2 via the cross-database call, the new user context has to trust the original login. There are two ways to do this, the quick and dirty and opens-up-possible-security-holes way, and the more complicated but safer way:
Quick and not entirely safe: alter database DB1 set trustworthy on.
Safe: Use signed modules
Third, in the general case you should check that the owner of DB1 and the owner of DB2 are the same (otherwise you can't cross database ownership chain): select owner_sid from sys.databases where name in ('DB1', 'DB2') But as with the first point, as a sysadmin you can take ownership of anything.
As too often happens, I failed to recognize a subtle difference between the two stored procedures: They both call a logging stored procedure, but this logging procedure has two variants, one with prefix sp_, and another one with the prefix usp. (Someone reacted to the Microsoft warning not to use sp_ as prefix.) The old one had an 'execute as owner' inside, which caused the error.
Replacing the function call with the new version fixed the error.
Sometimes the error is on the other side of the screen.
I last looked at Schemas (on Oracle) about 20 years ago, I know that Microsoft changed schemas in SQL Server 2005. We're now about to create a new application and I've long wanted to take another look at schemas.
We use 1 specific login to do the applications work so it has db_owner role and 1 specific login for running all reports so it has data_reader role.
I've done my research as well as poked around and wrote some scripts. This script "appears" to be all I need in order to create a schema:
CREATE SCHEMA [MySchema];
I used the sa user to create the schema and related tables. From there, I've been able to create tables within the schema and access them just fine from the two users.
My question is, was this very simple statement all that there is required to create a schema "correctly" and are there any specifics I should be watching out for?
We already access all db objects with the [dbo]. schema prefix in preparation for going multi-schema. I'm just not sure if there's something sneaky when we finally start getting into stored procedures, functions, views, indexes, foreign keys and the likes. So far all my testing has come up roses but I'm concerned I'm missing something that's going to really beat me with a stick some ways down the line.
This afternoon I was reviewing the security for a user in my SQL Server, in SQL Server Management Studio. I opened the Database User's Properties dialog, and went to the Securables section.
As I was cycling through the tables and stored procedures that this particular user had access to, I noticed that one of the data tables had the the Update option checked in an intermediate state. What does that mean? You can either update a row, or you can't. There is no in-between. I've included an image for reference. I would just fully check this option and save it but I'd rather not screw with the DB if this serves a worthwhile purpose.
I believe that means that that permission has been inherited and wasn't explicitly set for that user.
The GRANT statement can assign
permissions to a group or role that
can be inherited by database users.
http://msdn.microsoft.com/en-us/library/bb669084.aspx
I'm trying to find something that specifically spells out that's what the checkbox looks like in the above situation.
I'm converting database from Teradata to SqlServer. I've noticed all tables and procedures are named by the prefix "dbo." (e.g. "dbo.Table1").
I would like to know if and how I can get rid of "dbo" because it would make the conversion task a lot more easier.
dbo is not part of the table name. It is the name of the schema that the tables and stored procedures are attached to. dbo is the default schema in SQL server, though you can add others if needed.
See this MSDN article about them.
dbo is the schema, you can specify a new schema if you like. dbo is default is sql server.
All tables have to go into a schema. As durilai says, dbo is the "default" schema for SQL Server (it always exists). However, note that different users can have different default schemas (if more than one exists).
If you make reference to a table without specifying the schema, then SQL Server will search in your default schema for it (and the same goes for any other objects).
So, if your default schema is dbo, the following two statements are equivalent:
select * from Table1
select * from dbo.Table1
dbo is the default schema in SQL Server if no schema was set by user,
if you want you can create new schema and create tables to it.
Schemas are useful. For example, I used to grant an app login execute permission to every stored procedure separately. Now I grant the app login execute permission to the schema that contains all the stored procedures. This is much easier.
At least on my local instance, when I create tables, they are all prefixed with "dbo.". Why is that?
dbo is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace.
If you are using Sql Server Management Studio, you can create your own schema by browsing to Databases - Your Database - Security - Schemas.
To create one using a script is as easy as (for example):
CREATE SCHEMA [EnterSchemaNameHere] AUTHORIZATION [dbo]
You can use them to logically group your tables, for example by creating a schema for "Financial" information and another for "Personal" data. Your tables would then display as:
Financial.BankAccounts
Financial.Transactions
Personal.Address
Rather than using the default schema of dbo.
It's new to SQL 2005 and offers a simplified way to group objects, especially for the purpose of securing the objects in that "group".
The following link offers a more in depth explanation as to what it is, why we would use it:
Understanding the Difference between Owners and Schemas in SQL Server
Microsoft introduced schema in version 2005. For those who didn’t know about schema, and those who didn’t care, objects were put into a default schema dbo.
dbo stands for DataBase Owner, but that’s not really important.
Think of a schema as you would a folder for files:
You don’t need to refer to the schema if the object is in the same or default schema
You can reference an object in a different schema by using the schema as a prefix, the way you can reference a file in a different folder.
You can’t have two objects with the same name in a single schema, but you can in different schema
Using schema can help you to organise a larger number of objects
Schema can also be assigned to particular users and roles, so you can control access to who can do what.
You can generally access any object from any schema. However, it is possible to control which users have which access to particular schema, so you can use schema in your security model.
Because dbo is the default, you normally don’t need to specify it within a single database:
SELECT * FROM customers;
SELECT * FROM dbo.customers;
mean the same thing.
I am inclined to disagree with the notion of always using the dbo. prefix, since the more you clutter your code with unnecessary detail, the harder it is to read and manage.
For the most part, you can ignore the schema. However, the schema will make itself apparent in the following situations:
If you view the tables in either the object navigator or in an external application, such as Microsoft Excel or Access, you will see the dbo. prefix. You can still ignore it.
If you reference a table in another database, you will need its full name in the form database.schema.table:
SELECT * FROM bookshop.dbo.customers;
For historical reasons, if you write a user defined scalar function, you will need to call it with the schema prefix:
CREATE FUNCTION tax(#amount DECIMAL(6,2) RETURNS DECIMAL(6,2) AS
BEGIN
RETURN #amount * 0.1;
END;
GO
SELECT total, dbo.tax(total) FROM pricelist;
This does not apply to other objects, such as table functions, procedures and views.
You can use schema to overcome naming conflicts. For example, if every user has a personal schema, they can create additional objects without having to fight with other users over the name.
Something from Microsoft (Documentation)
The dbo user is a special user principal in each database. All SQL Server administrators, members of the sysadmin fixed server role, sa login, and owners of the database, enter databases as the dbo user. The dbo user has all permissions in the database and cannot be limited or dropped. dbo stands for database owner, but the dbouser account is not the same as the db_owner fixed database role, and the db_owner fixed database role is not the same as the user account that is recorded as the owner of the database.
The dbo user owns the dbo schema. The dbo schema is the default schema for all users, unless some other schema is specified. The dbo schema cannot be dropped.
The dbo user owns the dbo schema. The dbo schema is the default schema for all users, unless some other schema is specified. The dbo schema cannot be dropped.
DBO is the default schema in SQL Server. You can create your own schemas to allow you to better manage your object namespace. As a best practice, I always add the "DBO." prefix even though it is not necessary. Most of the time in SQL it's good to be explicit.