Is there any way to CREATE a table on SQL Server 2008 R2 by referencing the table name with a synonym? Also how can I detect if any object (the base object) is existing in the database by its synonym?
I've recently discovered that you can create a synonym for an object that does not even exist in the database. It is kind of weird. But it might just be VERY useful for an implementation I'm trying to do.
So if I need to create a table named dbo.Customer, I want to do the following-
/* The table dbo.Customer has not been created in the database yet */
CREATE SYNONYM Customer_Synonym FOR dbo.Customer
/* I know the lines below will give the wrong result (the object_id detection part)
* and an error (the create table part), cause I've tried it.
* I want to know if there is any simple work around for this
*/
IF OBJECT_ID(N'Customer_Synonym') IS NOT NULL
CREATE TABLE Customer_Synonym
(
cust_id INT NOT NULL
, cust_name VARCHAR(100) NOT NULL
...
...
);
Any help or suggestion will be very much appreciated. Thanks.
Related
I'm using SQL Server 2014 and trying to figure out some not trivia task.
I have a table PROPERTY and need to copy some of the data to absolutely new table PROPERTY_1 (PROPERTY_1 is not created and I'm not allowed to use CREATE TABLE). I have to use INSERT only!
I've googled some fancy commands like INSERT INTO from MySQL:
INSERT INTO PROPERTY_1 SELECT * FROM PROPERTY
but it's no help because (surprise-surprise!) PROPERTY_1 is not created.
Is it any possible way to pass this task or it's just some kind of weird task?
You must use Select Into as described in the Microsoft: documentation
You can use Select into to create the structure only and use Insert into to copy the data like below:
SELECT * INTO PROPERTY_1 FROM PROPERTY WHERE 1=0
INSERT INTO PROPERTY_1 SELECT * FROM PROPERTY
Benefits of using Select into to create the structure of the copy table:
You don't need to worry about the columns and their data types in the new table (PROPERTY_1) as those will be similar to the base table (PROPERTY). The new table schema will match the original schema, including identity columns.
There won't be any errors while inserting the records in the new table.
Is there any way in DB2 to find temp table from the session ?
I have created a temp table pertaining to session
DECLARE GLOBAL TEMPORARY TABLE SESSION.TEMP_TABLE_NAME
(
COL_1 VARCHAR(11) NOT NULL,
COL_2 VARCHAR(10)
) ON COMMIT PRESERVE ROWS;
When I am trying to create query
select * from sysibm.systables where owner='SESSION' and name='TEMP_TABLE_NAME'
yields 0 rows.
Am I looking at the incorrect table to find temp tables ?
Thanks !
A declared global temporary table ( DGTT) will not appear in the catalog, this is the design - so you will not find a DGTT in sysibm.systables. A DGTT cannot be used by any other program except the one that declares it - it is specific to that session, hence there's no value to having it in the catalogue.
If you are using Db2 for z/OS (v10 or higher), or Db2-LUW, you may need instead, a "CREATED global temporary table" (CGTT) which uses a different syntax create global temporary table ... These are catalogued, but you need relevant permissions to create them.
See the Db2-LUW documentation.
or for Db2 for z/OS here.
Look at the SYSIBMADM.ADMINTEMPTABLES administrative view.
If you want to see all the DGTTs created in your session, then:
SELECT TABNAME
FROM SYSIBMADM.ADMINTEMPTABLES
WHERE TEMPTABTYPE='D'
AND APPLICATION_HANDLE=mon_get_application_handle();
I am trying to create a table in Sybase and i get getting the same syntax error. Which is ASA Error -131: Syntax error near '(' on line 1
Here is my create table script:
CREATE TABLE tablename
(NUM_PO BIGINT DEFAULT AUTOINCREMENT,
MNT NUMERIC(9) NULL,
QTY_PROD NUMERIC(9) NULL,
NUMERIC(14) NULL
PRIMARY KEY (NUM_PO)
);
It appears you are trying to specify the database the table should be created in. In SQL-server, sometimes it would nag if you didn't put the owner of the table creating it within the database. I looked at SyBase's create table, and I think you just need to make a slight shift
create table IDW.tablename
to
create table IDW..tablename
The "IDW" appears to be your database. the extra period via ".." would imply that whoever you are connected as is the table owner, or just goes to default owner value, THEN the table name.
Hope this helps.
Unless I am missing something the definition of the last column is incomplete. Only the data type is provided.
See if the error disappears once you fix this. Otherwise the table DDL looks perfect. I verified with the Sybase manual too.
in postgres sql creating the table as select dropped the not null constraints on the table.
for example :
create table A (char a not null);
create table B as select * from a;
select * from B;-- no constraint is copied from A table
please let me know how to copy table data as well as constraints in postgres.
There is no single-command solution to this.
To create a table based on an existing one, including all constraints, use:
create table B ( like a including constraints);
Once you have done that, you can copy the data from the old one to the new one:
insert into b
select * from a;
If you do this in a single transaction, it looks like an atomic operation to all other sessions connected to the database.
very detailed and nicely explained tutorial for create table command in PostgreSQL 9.1
http://www.postgresql.org/docs/current/static/sql-createtable.html
Not null constraints are always copied (if creating table by giving reference of parent table in create table command) and even with including constraints, only check constraint will be copied.
I am using a Sybase database and would like to know if it's valid to have a table contain a column with the same name as that of the table, e.g.:
CREATE TABLE foo
(
foo int not null,
etc...
)
Valid? Sure. Recommended? No.
Yes, we can surely do that but as said it is not recommended. But why are we able to do so? Well, because a table name entry goes into the system table sysobjects however column entries go in the system table syscolumns.
Therefore there is no restriction in using table name as column name, however using table name as column name usually is not recommended because it makes your table structure a bit confusing and also it adds bad practice to database design.