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.
Related
How do I drop a few tables (e.g. 1 - 3) using the output of a SELECT statement for the table names? This is probably standard SQL, but specifically I'm using Apache Impala SQL accessed via Apache Zeppelin.
So I have a table called tables_to_drop with a single column called "table_name". This will have one to a few entries in it, each with the name of another temporary table that was generated as the result of other processes. As part of my cleanup I need to drop these temporary tables whose names are listed in the "tables_to_drop" table.
Conceptually I was thinking of an SQL command like:
DROP TABLE (SELECT table_name FROM tables_to_drop);
or:
WITH subquery1 AS (SELECT table_name FROM tables_to_drop) DROP TABLE * FROM subquery1;
Neither of these work (syntax errors). Any ideas please?
even in standard sql this is not possible to do it the way you showed.
in standard sql usually you can use dynamic sql which impala doesn't support.
however you can write an impala script and run it in impala shell but it's going to be complicated for such task, I would prepare the drop statement using select and run it manually if this is one-time thing:
select concat('DROP TABLE IF EXISTS ',table_name) dropstatements
from tables_to_drop
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"
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)
I want to do something like
DROP PROJECTION IF EXISTS myProjection;
Apparently I can use IF EXISTS for a table but not a projection.
I understand if I drop the table with CASCADE, that should drop the corresponding projections, but I apparently have some orphaned projections which I do not have a track of. And sometimes when I rename tables/projections, it fails saying projection already exists.
The Drop Projection page and this stackoverflow page for generic sql do not help much.
Edit: I am using this in Mybatis Migrations. So my entire migration would fail if there is an error in any of the scripts. So, no I can not ignore the error.
If there is no IF EXISTS for a projection -- is there a programatic way (LIKE TSQL/PLSQL) where I could specify a condition to check if the projection exists and take an action whether to drop it or not?
There is no drop projection IF EXISTS .... You can just use drop projection ... and - of course - you will get an error message if the projection you're trying to delete does not exists.
You can list ALL projections for a given schema/table using a SQL like this:
\set schema '''my_schema'''
\set table '''my_table'''
select
projection_name,
sum(row_count) as row_count,
sum(used_bytes) as used_bytes,
sum(wos_row_count) as wos_row_count,
sum(wos_used_bytes) as wos_used_bytes,
sum(ros_row_count) as ros_row_count,
sum(ros_used_bytes) as ros_used_bytes
from
projection_storage
where
anchor_table_schema = :schema and
anchor_table_name = :table
group by 1
order by 1
;
And the following will list all projections associated with tables in a given schema:
\set schema '''my_schema'''
select
projection_name,
anchor_table_name,
sum(row_count) as row_count,
sum(used_bytes) as used_bytes,
sum(wos_row_count) as wos_row_count,
sum(wos_used_bytes) as wos_used_bytes,
sum(ros_row_count) as ros_row_count,
sum(ros_used_bytes) as ros_used_bytes
from
projection_storage
where
anchor_table_schema = :schema
group by 1, 2
order by 1, 2
;
you can query catalog table in vertica, this will give you schema names of all present schemas ,
select v_catalog.columns from v_catalog.columns;
i sometime use this select query , which gives me evey info related to a table
select export_objects('','your_schema.table_name');
This is possible since Vertica 9.2.x.
DROP PROJECTION IF EXISTS myProjection;
Reference: https://www.vertica.com/docs/9.2.x/HTML/Content/Authoring/SQLReferenceManual/Statements/DROPPROJECTION.htm
I was reading about Table Value Parameter which seems interesting.. but i want to know that when we define a table type in database where does it get saved? What is its scope? And How can i modify that type .. suppose i created a table type as...
CREATE TYPE DeptType AS TABLE
(
DeptId INT, DeptName VARCHAR(30)
);
Now how can i get the schema of DeptType in future? In case of stored procedure its as simple as sp_helptext [ProcedureName]. How can i modify it? What is the scope of this type?
Try this query -
SELECT *
FROM sys.columns c
JOIN sys.table_types tt ON c.[object_id] = tt.type_table_object_id
WHERE tt.name = 'DeptType'
SELECT *
FROM sys.objects o
WHERE o.[type] = 'TT'
AND o.name LIKE 'TT_DeptType%'
How to modify -
Database Explorer ->
<your db> ->
Programmability ->
Types ->
User-Defined Table Types -> DROP-CREATE script
What is its scope?
It belongs to a schema, the same as a table, view, stored procedure, etc, would. For usage, it can only be used within the same database as it resides. There's no way to reference a table type from another database (even within the same instance), and two table types declared identically in separate databases are not interchangable.
And How can i modify that type
You cannot, unfortunately. The pattern to SQL commands is that if CREATE is used to bring an object into existence, ALTER is used to modify that object (And DROP to remove it). By looking at the ALTER statements, you'll note that there is no ALTER TYPE.
The best you can do is DROP the type and CREATE it again with its altered form. Unfortunately, to do so you have to drop all dependent objects first, then drop the type, then create it, then recreate all dependent objects.