Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

 All Forums
 SQL Server 2005 Forums
 Transact-SQL (2005)
 Using another db in a stored proc

Author  Topic 

dmilam
Posting Yak Master

185 Posts

Posted - 2010-09-28 : 14:44:22
How to use an object from another database in a stored procedure?

"Database name 'tempdb' ignored, referencing object in tempdb."
"Invalid object name #temp"

Any workaround? I want the stored proc to exist in T so that it's relatively permanent and usable by other callers, but the source table is in tempdb.

In other words, T..storedProc calls tempdb..#temp and fails.

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2010-09-28 : 14:49:51
You do not need to reference tempdb when calling a temp table.

So just reference #temp, and not tempdb.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

dmilam
Posting Yak Master

185 Posts

Posted - 2010-09-28 : 14:59:29
Thanks; still getting "Invalid object name #temp"

@tablename is one of two variables I am passing into the proc with dynamic sql in the body of the proc holding the variable, like so:


select top '+cast(@recordcount as varchar)+' CustomerID
into T..random_'+@tablename+'
from (
select distinct CustomerID
from #'+@tablename+'
) s
Go to Top of Page

dmilam
Posting Yak Master

185 Posts

Posted - 2010-09-28 : 15:02:37
Should add, that it's not really "#temp", but "#tablename", so that the temp table and the proc variable have the same name, except for the "#"
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2010-09-28 : 15:03:18
Ah you are using dynamic SQL, that makes a huge difference.

Could you post your code?

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

dmilam
Posting Yak Master

185 Posts

Posted - 2010-09-29 : 20:54:20
Here's the code. (Incidentally, I have trouble posting at times -- must be the network where I'm sitting, daytime.)


DROP PROCEDURE uspRandomize
GO

CREATE PROCEDURE uspRandomize
@tablename AS NVARCHAR(25),
@recordcount AS INT = 0
AS

SET NOCOUNT ON

DECLARE @message AS NVARCHAR(500)

IF @tablename = ''
BEGIN
SET @message = 'You did not enter a table name'
SELECT @message
RETURN 1
END
ELSE

IF @recordcount < 1
BEGIN
SET @message = 'You did not enter a record count'
SELECT @message
RETURN 1
END
ELSE

BEGIN

declare @sql as nvarchar(4000)

-- Random table holding desired count
set @sql = '
if object_id(N''T..random_'+@tablename+''') is not null
begin
drop table T..random_'+@tablename+'
end
'
exec sp_executesql @sql

-- Insert number of desired records
set @sql = '
select top '+cast(@recordcount as varchar)+' CustomerID
into T..random_'+@tablename+'
from (
select distinct CustomerID
from '+@tablename+'
) s
order by newid() -- a large recordset it will have a severe performance impact
'
exec sp_executesql @sql

-- Return result set containing the selected records
set @sql = '
SELECT Count(CustomerID) AS "Random Count"
FROM T..random_'+@tablename
exec sp_executesql @sql

-- Check for duplicates
set @sql = '
SELECT CustomerID AS "Duplicates"
FROM T..random_'+@tablename+'
GROUP BY CustomerID
HAVING COUNT(CustomerID) > 1
'
exec sp_executesql @sql

END

GO

--Usage
exec uspRandomize @tablename = <name of table>, @recordcount = <choose amount>


The problem may be that I'm testing this in another session than that of the temp table. But another problem arises when I attempt to INSERT the results into another temp table. The record count is not inserted, but the literal string of whatever count is chosen (resulting in a row count of 1 rather than the amount).
Go to Top of Page

tkizer
Almighty SQL Goddess

38200 Posts

Posted - 2010-09-30 : 13:31:55
I do not see a temp table in the code you posted.

You should really reconsider your database design and stored procedure code. If you require that the table names be dynamic, then you likely are not properly normalized. Store all of the random_ data into one table.

Tara Kizer
Microsoft MVP for Windows Server System - SQL Server
http://weblogs.sqlteam.com/tarad/

Subscribe to my blog
Go to Top of Page

dmilam
Posting Yak Master

185 Posts

Posted - 2010-09-30 : 14:13:25
Oops, I posted my final workaround rather than my problem! Design and normalization here... that's another problem indeed.
Go to Top of Page
   

- Advertisement -