What is the purpose of the two dots in the following SQL statement?
select * from msdb..backupset
I understand that one would mean select from the table called 'backupset' with the 'msdb' database. But two dots is doing something different, which I do not understand.
The login would have default "schema" on the database that is connected to (in your case msdb). Specifying the object (in your case "backupset") with 3-part name like [DB name]..[Object Name] is omitting of the schema name (in your case probably "dbo") in the 3-part name.
There could be MyDatabase.SchemaA, and MyDatabase.SchemaB on a database MyDatabase database, and each schema could have 2 separate tables with same object name -- like MyDatabase.SchemaA.MyTable, and MyDatabase.SchemaB.MyTable.
If your login to MyDatabase defaults to SchemaA, and and run SELECT * FROM MyDatabase..MyTable, then you would be selecting from MyDatabase.SchemaA.MyTable.
If you wanted to select from the second table, you'd have to SELECT * FROM MyDatabase.SchemaB.MyTable or SELECT * FROM SchemaB.MyTable
Typically it is said that specifying the schema name explicitly is good practice (instead of backupset or MyTable, write dbo.backupset or SchemaA.MyTable
Using the two dots in this three-part naming convention (i.e Database.schema.table) indicates that the schema is the default schema(dbo)
Related
I am quite new to SQL, and my first "job" is to get something out of an Oracle SQL database.
Just to see what's actually found in my connection I use the following:
SELECT owner, table_name FROM dba_tables
This gives me a bunch of tuples with an owner name and table_name. However, some table names are the same for different owners.
So when I run a command like:
SELECT * FROM MyTableName
How do I ensure that this table is coming from owner1 and not owner2, where both of them actually have a table called MyTableName ?
You can do:
SELECT * FROM <owner>.MyTableName
You can specify exactly which table with
select * from some_owner.my_table;
If you do this:
select * from my_table;
You will be selecting from the version of MY_TABLE that belongs to the owner/user with which you you are connected to the database. So, if you connected as user SCOTT, then
select * from my_table;
effectively becomes
select * from scott.my_table;
Note that this behavior can be overridden by the use of synonyms. Suppose user SCOTT has a synonym like this:
create synonym scott.my_table for fred.my_table;
Then SCOTT issues
select * from my_table;
Then oracle will check first for a synonym, and finding it will effectively transform the query to
select * from fred.my_table;
So in the end, the precedence is this. When you reference a table without qualifying it with the owner, oracle will look for it in this sequence:
is there a user synonym by that name? if so, use what it references if the user has been granted necessary privileges.
is there a global synonym by that name? if so, use what it references if the user has been granted necessary privileges.
does the user itself own a table by that name? if so, use that table.
return error "ORA-00942: table or view does not exist"
I'm using PostgreSQL server on my Windows.
I have created table user(id, name, age) and inserted some data there.
When I'm trying to retrieve that data via SELECT ALL FROM user I'm getting only the rows count and just plain nothingness.
How it looks like in psql CLI:
...and I'm also receiving empty object array as query result in my nodejs app:
Postgres supports SELECT ALL as a synonym for SELECT -- as a two words syntax parallel to SELECT DISTINCT. The ALL does nothing.
In addition, Postgres -- unlike other databases -- allows a SELECT to select no columns.
So:
SELECT ALL
FROM user;
Selects all the rows from user but no columns. In general, you would instead write:
SELECT *
FROM user;
to see the contents of the rows. If you want to be verbose, yo could use:
SELECT ALL *
FROM user;
But that is used somewhere close to never in practice.
You specified that you want the data from the column named "all". To get data from all columns you need to specify them all or use the asterisk symbol like so:
SELECT * FROM "user";
I have a script in ASP Classic that uses a Firebird database. I would like to execute a query without "quotation marks"
Now I must write this:
SQL = "SELECT ""TArticoli"".""IDArticolo"",""TArticoli"".""Desc"" FROM ""TArticoli"";"
I would write this:
SQL = "SELECT TArticles.IDArticle, TArticles.Desc FROM TArticles;"
The first one is accepted the second not, how can I do this?
You can't. DESC is a reserved word in Firebird, so to be able to use it as a column name (or any other object name for that matter), you will need to enclose it in quotes.
A second problem is that you are currently using
SELECT "TArticoli"."IDArticolo","TArticoli"."Desc" FROM "TArticoli"
And this means both your table name and the column names are case sensitive, and in that case, quoting those object names is mandatory. Unquoted object names are case insensitive, but are mapped to object names in upper case. This means that select * from TArticoli will select from a table called TARTICOLI, while select * from "TArticoli", selects from a table called TArticoli.
So unless you are going to rename or recreate all your tables or columns, you will not be able to get rid of quotes. The only thing you can do to reduce the number of quotes, is by not prefixing the columns with the table names (in the query shown it isn't necessary), or otherwise use a case insensitive alias for the table, eg
SELECT "IDArticolo", "Desc" FROM "TArticoli"
or
SELECT a."IDArticolo", a."Desc" FROM "TArticoli" AS a
Lets suppose I have two schemas in one DB: public and private. In both schemas I have the same table - my_table with the same columns. So is it normal to do the following:
SELECT public.my_table.my_col FROM public.my_table?
I am trying to do it with H2 but get exception in ResultSet - column not found. Is it not normal or it's not normal for H2?
You should write:
SELECT my_col FROM public.my_table
since column names are already evaluated in the table(s) specified in the query.
I have a sql 2005 database and I have a table named dbo.AgencyProfile
However, I want to remove the dbo prefix. How can I accomplish this?
You cannot remove the prefix/schema but you can change it by recreating the table:
CREATE TABLE [whatever].[AgencyProfile](
[AgencyId] [int] NOT NULL DEFAULT
[AgencyName] [nvarchar](256),
[Field 2] [nvarchar](256),
[Field 3] [uniqueidentifier] NOT NULL
etc....
Why do you need to? SQL keeps all objects in the dbo schema my default. You don't need to use the schema in your SQL statements - SELECT * FROM AgencyProfile will do fine because SQL will search the dbo schema for AgencyProfile.
You can put objects into your own schemas, but then you do need to qualify them with your schema name.
The schema is an integral part of the object: you can only remove it from code that refers to the object
There is a performance hit at compile time because it has to resolve what schema the object is in.
SELECT * FROM foobar is not the same SELECT * FROM dbo.foobar and will require a check to see what schema foobar is in. That is, it will look for [domain\user].foobar before going to dbo.foobar.
From "Execution Plan Caching and Reuse":
...
The algorithms to match new SQL statements to existing, unused
execution plans in the cache require
that all object references be fully
qualified. For example, the first of
these SELECT statements is not matched
with an existing plan, and the second
is matched:
SELECT * FROM Contact
SELECT * FROM Person.Contact
And for NT connections you can't specify default schema so can't avoid this
And if you want SCHEMABINDING in views etc then you have to qualify schema.
etc
It's far more than "code clutter"
Edit: after your comment elsewhere...
You have run create table with no schema so you have an object [domain\user].AgencyProfile. Of course dbo.AgencyProfile does not exist
You need to run 'ALTER AUTHORIZATION ON [domain\user].AgencyProfile TO dbo' which replaces sp_changeobjectowner
You can't remove the prefix/schema, but as Andy points out you don't have to use it if you don't have other schemas in the database.