Hi I have a temporary table in which I am trying to insert records based on a where condition but it throws an error that it already exists.
I have tried to change the names but that is not the issue as the temporary tables are delete when the session ends.
I think I am writing the query right.
SELECT [Name]
INTO #TEMP_REJECT
FROM #TEMP_VALIDATION
WHERE Name = #Name
I am trying to insert #TEMP_REJECT FROM #TEMP_VALIDATION
Error message
"There is already an object named '#TEMP_REJECT' in the database."
Please suggest.
Thank you for your help.
R
SQL Server won't tell you that a table doesn't exist if it doesn't.
I suggest that you add
IF OBJECT_ID('tempdb..#TEMP_REJECT') IS NOT NULL
DROP TABLE #TEMP_REJECT
in front of your select statement. This guarantees that the temp table won't exist when the select is executed.
So your statement becomes
IF OBJECT_ID('tempdb..#TEMP_REJECT') IS NOT NULL
DROP TABLE #TEMP_REJECT
SELECT [Name]
INTO #TEMP_REJECT
FROM #TEMP_VALIDATION
WHERE Name = #Name
This answer will help you :
https://stackoverflow.com/a/8560644/3635715
To make short : SELECT INTO creates table then insert records.
INSERT INTO only insert the records.
So in your case, since #TEMP_REJECT already exists, SELECT INTO is rejected because it cannot create the table again, so you have to use INSERT INTO after first SELECT INTO.
IF OBJECT_ID('tempdb..#TEMP_REJECT') IS NOT NULL
BEGIN
INSERT INTO #TEMP_REJECT
SELECT [Name]
FROM #TEMP_VALIDATION
WHERE Name = #Name
END
ELSE
BEGIN
SELECT [Name]
INTO #TEMP_REJECT
FROM #TEMP_VALIDATION
WHERE Name = #Name
END
References :
INTO Clause
INSERT Clause
Try checking before inserting
if object_id('tempdb..#TEMP_REJECT') is not null
drop table #TEMP_REJECT
SELECT [Name]
INTO #TEMP_REJECT
FROM #TEMP_VALIDATION
WHERE Name = #Name
if SQL says,there is temp table,there must be a table prior to your insert
I've noticed that I get the same error when I am working consecutively through the same SQL Server tab/file.
For example, I have a large SQL file that I use to execute a series of updates using temp tables. When I execute it consecutively, it errors out complaining that my #tempTable already exists (even if I use a "if this table exists, drop it" statement as DeanOC describes).
Exiting out of the file/tab between consecutive runs resolves the issue.
If this poses an issue for your use case, I'd suggest bundling your statements in a stored proc and implementing DeanOC's drop logic therein.
Related
I tried to use two insert into statements in one stored procedure like this:
CREATE PROCEDURE dbo.test
AS
BEGIN
DROP TABLE IF EXISTS #temp;
SELECT *
INTO #temp
FROM sys.column_master_keys AS CMK;
-- some statement
-- some statement
-- some statement
DROP TABLE IF EXISTS #temp;
SELECT *
INTO #temp
FROM INFORMATION_SCHEMA.COLUMNS AS C;
END;
Error message :
There is already an object named '#temp' in the database.
How to use one temporary table for many insert into in one stored procedure?
This is occurring because the code is compiled before it is run. During the compilation phase, SQL Server sees the two INSERT statements that create the table. It does not execute them, because it is only devising the execution plans.
Because the code is not being executed, the compilation phase misses the DROP TABLE. Alas. It sees that the table already exists when the second is executed, generating the error.
In any case, this is very easily fixed by giving the tables different names.
You can use one temporary table for many insert into statements in one stored procedure.To make it happen you have to use dynamic SQL.
CREATE PROCEDURE dbo.test
AS
BEGIN
DROP TABLE IF EXISTS #temp;
EXEC('SELECT *
INTO #temp
FROM sys.column_master_keys AS CMK;')
-- some statement
-- some statement
-- some statement
DROP TABLE IF EXISTS #temp;
EXEC('SELECT *
INTO #temp
FROM INFORMATION_SCHEMA.COLUMNS AS C;')
END;
I have a SQL script that is setting up two database tables with their keys and constraints without any problem. I won't include the whole code but the 'skeleton' of it looks like this:
BEGIN
CREATE TABLE [table] (
)
CREATE TABLE [table2] (
)
ALTER TABLE table...
ALTER TABLE table2....
END
I am stuck trying to add stored procedures to this script though, ideally I would like to include this all within the same script. Could someone tell me how to include the following stored procedure into the above script?
CREATE PROCEDURE Test
#x int
AS
BEGIN
SELECT COUNT(*)
FROM table
END
GO
I have tried putting it towards the end of the script and have also tried with and without the BEGIN, END and GO tags but I keep getting an error that says 'incorrect syntax near PROCEDURE'.
Try it like this:
USE BDNAME
GO
BEGIN
CREATE TABLE [table] (
)
CREATE TABLE [table2] (
)
ALTER TABLE table...
ALTER TABLE table2....
END
USE BDNAME
GO
CREATE PROCEDURE Test
#x int
AS
BEGIN
SELECT COUNT(*)
FROM table
END
GO
Instead of using BEGIN END, put GO between all your Statements like Create, Alter. Also I would like to inform you that putting GO will create blocks in your script, so if you create some local variable in one block, it is not accessible in another.
CREATE Table Table1(
--Your Code
)
GO
CREATE PROCEDURE Test
#x int
AS
BEGIN
SELECT COUNT(*)
FROM Table1
END
GO
--Continue your script
Hope this helps.
If I try to execute the following code, I get the errors
Msg 207, Level 16, State 1, Line 3 Invalid column name 'Another'. Msg
207, Level 16, State 1, Line 4 Invalid column name 'Another'.
even though the predicate for both IF statements always evaluates to false.
CREATE TABLE #Foo (Bar INT)
GO
IF (1=0)
BEGIN
SELECT Another FROM #Foo
END
GO
IF (1=0)
BEGIN
ALTER TABLE #Foo ADD Another INT
SELECT Another FROM #Foo
END
GO
DROP TABLE #Foo
This is probably over-simplified for the sake of the example; in reality what I need to do is select the values from a column, but only if the column exists. If it doesn't exist, I don't care about it. In the problem that drove me to ask this question, my predicate was along the lines of EXISTS (SELECT * FROM sys.columns WHERE object_id = #ID AND name = #Name). Is there a way to achieve this without resorting to my arch-enemy Dynamic SQL? I understand that my SQL must always be well-formed (i.e. conform to grammar) - even within a block that's never executed - but I'm flabbergasted that I'm also being forced to make it semantically correct too!
EDIT:
Though I'm not sure the code below adds much to the code above, it's a further example of the problem. In this scenario, I only want to set the value of Definitely (which definitely exists as a column) with the value from Maybe (which maybe exists as a column) if Maybe exists.
IF EXISTS (SELECT * FROM sys.columns WHERE object_id = OBJECT_ID('dbo.TableName', 'U') AND name = 'Maybe')
BEGIN
UPDATE dbo.TableName SET Definitely = Maybe
END
SQL Server doesn't execute line by line. It isn't procedural like .net or Java code. So there is no "non-executed block"
The batch is compiled in one go. At this point, the column doesn't exist but it knows the table will be. Table does not have a column called "Another". Fail.
Exactly as expected.
Now, what is the real problem you are trying to solve?
Some options:
2 tables or one table with both columns
use Stored procedures to decouple scope
not use temp tables (maybe not needed; it could be your procedural thinking...)
dynamic SQL (from Mitch's deleted answer)
Edit, after comment;
Why not hide schema changes behind a view, rather than changing all code to work with columns that may/may not be there?
You can use EXEC to handle it. It's not really dynamic SQL if the code never actually changes.
For example:
CREATE TABLE dbo.Test (definitely INT NOT NULL)
INSERT INTO dbo.Test (definitely) VALUES (1), (2), (3)
IF EXISTS (SELECT *
FROM sys.columns
WHERE object_id = OBJECT_ID('dbo.Test', 'U') AND
name = 'Maybe')
BEGIN
EXEC('UPDATE dbo.Test SET definitely = maybe')
END
SELECT * FROM dbo.Test
ALTER TABLE dbo.Test ADD maybe INT NOT NULL DEFAULT 999
IF EXISTS (SELECT *
FROM sys.columns
WHERE object_id = OBJECT_ID('dbo.Test', 'U') AND
name = 'Maybe')
BEGIN
EXEC('UPDATE dbo.Test SET definitely = maybe')
END
SELECT * FROM dbo.Test
DROP TABLE dbo.Test
You can also try Martin Smith's "Workaround" using a non-existing table to get "deferred name resolution" for columns.
I had the same issue.
We are creating a script for all changes for years and this is the first time that we have this issue.
I've tried all your answers and didn't find the issue.
In my case it was because of temporary table within the script that I'm using also within a stored procedure, although every sentence has go.
I've found that if I'm adding if exists with drop to the temporary table after the script is using the temporary table, it is working correctly.
Best regards,
Chen
Derived from the answer by #gbn.
What i did to solve the issue was to use 'GO' between the ALTER query and the query that uses the column added by ALTER. This will make the 2 queries to be run as separate batches thereby ensuring your 'Another' column is there before the SELECT query.
I have a Stored Procedure in MSSQL 2008, inside of this i've created a Temporary Table, and then i executed several inserts into the temporary Table.
How can i select all the columns of the Temporary Table outside the stored procedure? I Mean, i have this:
CREATE PROCEDURE [dbo].[LIST_CLIENTS]
CREATE TABLE #CLIENT(
--Varchar And Numeric Values goes here
)
/*Several Select's and Insert's against the Temporary Table*/
SELECT * FROM #CLIENT
END
In another Query i'm doing this:
sp_configure 'Show Advanced Options', 1
GO
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
GO
SELECT *
INTO #CLIENT
FROM OPENROWSET
('SQLOLEDB','Server=(local);Uid=Cnx;pwd=Cnx;database=r8;Trusted_Connection=yes;
Integrated Security=SSPI',
'EXEC dbo.LIST_CLIENTS ''20110602'', NULL, NULL, NULL, NULL, NULL')
But i get this error:
Msg 208, Level 16, State 1, Procedure LIST_CLIENTS, Line 43
Invalid object name '#CLIENT'.
I've tried with Global Temporary Tables and It doesn't work.
I know that is the scope of the temporary table, but, how can i get the table outside the scope of the SP?
Thanks in advance
I think there is something deeper going on here.
One idea is to use a table variable inside the stored procedure instead of a #temp table (I have to assume you're using SQL Server 2005+ but it's always nice to state this up front). And use OPENQUERY instead of OPENROWSET. This works fine for me:
USE tempdb;
GO
CREATE PROCEDURE dbo.proc_x
AS
BEGIN
SET NOCOUNT ON;
DECLARE #x TABLE(id INT);
INSERT #x VALUES(1),(2);
SELECT * FROM #x;
END
GO
SELECT *
INTO #client
FROM OPENQUERY
(
[loopback linked server name],
'EXEC tempdb.dbo.proc_x'
) AS y;
SELECT * FROM #client;
DROP TABLE #client;
DROP PROCEDURE dbo.proc_x;
Another idea is that perhaps the error is occurring even without using SELECT INTO. Does the stored procedure reference the #CLIENT table in any dynamic SQL, for example? Does it work when you call it on its own or when you just say SELECT * FROM OPENROWSET instead of SELECT INTO? Obviously, if you are working with the #temp table in dynamic SQL you're going to have the same kind of scope issue working with a #table variable in dynamic SQL.
At the very least, name your outer #temp table something other than #CLIENT to avoid confusion - then at least nobody has to guess which #temp table is not being referenced correctly.
Since the global temp table failed, use a real table, run this when you start your create script and drop the temp table once you are done to make sure.
IF OBJECT_ID('dbo.temptable', 'U') IS NOT NULL
BEGIN
DROP TABLE dbo.temptable
END
CREATE TABLE dbo.temptable
( ... )
You need to run the two queries within the same connection and use a global temp table.
In SQL Server 2008 you can declare User-Defined Table Types which represent the definition of a table structure. Once created you can create table parameters within your procs and pass them a long and be able to access the table in other procs.
I guess the reason for such behavior is that when you call OPENROWSET from another server it firstly and separately requests the information about procedure output structure (METADATA). And the most interesting thing is that this output structure is taken from the first SELECT statement found in the procedure. Moreover, if the SELECT statement follows the IF-condition the METADATA request ignores this IF-condition, because there is no need to run the whole procedure - the first met SELECT statement is enough. (By the way, to switch off that behavior, you can include SET FMTONLY OFF in the beginning of your procedure, but this might increase the procedure execution time).
The conclusions:
— when the METADATA is being requested from a temp table (created in a procedure) it does not actually exists, because the METADATA request does not actually run the procedure and create the temp table.
— if a temp table can be replaced with a table variable it solves the problem
— if it is vital for the business to use temp table, the METADATA request can be fed with fake first SELECT statement, like:
declare #t table(ID int, Name varchar(15));
if (0 = 1) select ID, Name from #t; -- fake SELECT statement
create table #T (ID int, Name varchar(15));
select ID, Name from #T; -- real SELECT statement
— and one more thing is to use a common trick with FMTONLY (that is not my idea) :
declare #fmtonlyOn bit = 0;
if 1 = 0 set #fmtonlyOn = 1;
set fmtonly off;
create table #T (ID int, Name varchar(15));
if #fmtonlyOn = 1 set fmtonly on;
select ID, Name from #T;
The reason you're getting the error is because the temp table #Client was not declared before you ran the procedure to insert into it. If you declare the table, then execute the list proc and use direct insert -
INSERT INTO #Client
EXEC LIST_CLIENTS
I have a SQL script that populates a temp column and then drops the column at the end of the script. The first time it runs, it works fine because the column exists, then it gets dropped. The script breaks the 2nd time because the column no longer exists, even though the IF statement ensures that it won't run again. How do I get around SQL checking for this field?
IF EXISTS (SELECT name FROM syscolumns
WHERE name = 'COLUMN_THAT_NO_LONGER_EXISTS')
BEGIN
INSERT INTO TABLE1
(
COLUMN_THAT_NO_LONGER_EXISTS,
COLUMN_B,
COLUMN_C
)
SELECT 1,2,3 FROM TABLE2
ALTER TABLE TABLE1 DROP COLUMN COLUMN_THAT_NO_LONGER_EXISTS
END
I had a similar problem once and got round it by building all the queries as strings and executing them using the Exec() call. That way the queries (selects, inserts or whatever) don't get parsed till they are executed.
It wasn't pretty or elegant though.
e.g
exec('INSERT INTO TABLE1(COLUMN_THAT_NO_LONGER_EXISTS,COLUMN_B,COLUMN_C) SELECT 1,2,3 FROM TABLE2')
Are you checking the column isnt on another table ? If not you probably to check the table too see if statement below.
If you are already doing that is it running a in a single transaction and not picking up the that dropped column has gone ?
IF Not EXISTS (SELECT name FROM sys.columns
WHERE name = 'COLUMN_THAT_NO_LONGER_EXISTS' and Object_Name(object_id) = 'Table1')
Created a quick script program for this; can you confirm this matches what you are trying to do because in SQL 2007 at least this isnt returning an error. If i create the table and run through with teh alter table to add colc it works; if i then run the if / insert that works even after dropping the table.
create table tblTests
(
TestID int identity (1,1),
TestColA int null,
TestColB int null
)
go -- Ran this on its own
insert into tblTests (TestColA, TestColB)
Select 1,2
go 10
-- Insert some initial data
alter table tblTests
add TestColC Int
go -- alter the table to add new column
-- Run this with column and then after it has removed it
IF EXISTS (SELECT name FROM sys.columns a
WHERE name = 'TestColC' AND
OBJECT_NAME(object_id) = 'tblTests')
Begin
insert into tblTests (TestColA, TestColB, testcolc)
select 1,2,3
alter table tblTests
drop column TestColC
End