Beg to differ.
If your first procedure contains
select
field1,
field2,
field3
into #t1
from table1
exec 2ndStoredProcedure
then 2ndStoredProcedure will be able to read #t1.
If this is not the case then we are in deep doodoo s as this is used on
daily basis in our system without a problem (apparently!)
Stuart
>>> "Daniel Morphett "
<mssqldba-ezmlmshield-x5702011.[Email address protected] 07/29/04
08:16am >>>
This is off the top of my head, so check it.
If you use global temp tables i.e. ##temp, I think you might run into
trouble, because the double hash sign means it can be read by more
than
one connection. So I would restrict your procs to using a local temp
table (one hash in name: #temp). However, you won't be able to use
this
if your proc calls another proc that also needs to refer to the temp
table, because it will then be out of scope.
Best thing to do is to try creating the temp table from one db, and
then
try reading it from the other (or read BOL on subject)
Daniel Morphett
DBA
Brilliant Digital Entertainment
02 9281 9272
-----Original Message-----
From: Entena Raymond
[mailto:mssqldba-ezmlmshield-x63384665.[Email address protected]
Sent: Thursday, July 29, 2004 5:09 PM
To: LazyDBA Discussion
Subject: FW: same temporary table and cursor names running on
different
DBs and same server
Hi,
Any thoughts on my concern below?
Thanks,
Ray
-----Original Message-----
From: Entena, Raymond
Sent: Thursday, July 29, 2004 10:43 AM
To: '[Email address protected]
Subject: same temporary table and cursor names running on different
DBs
and same server
Hi Guys,
I have the same set of stored procedure running on different DBs on
the
same server. This stored procedure is using temp tables and cursors.
The stored procedure will be scheduled to run everyday, synchronously.
Would this cause data and stored procedure inconsistencies considering
it's declaring the same set of temp tables and cursors?
Thanks in advance.
Ray
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
For additional commands, e-mail: mssqldba-[Email address protected]
---------------------------------------------------------------------
TO REPLY TO EVERBODY , PLEASE CLICK REPLY-ALL, NOT JUST REPLY
Website : http://www.LazyDBA.com
To unsubscribe: http://www.lazydba.com/unsubscribe.html
For additional commands, e-mail: mssqldba-[Email address protected]
*************************************************************************************
The contents of this email are confidential to the intended recipient.
It may not be disclosed to or used by anyone other than the addressee,
nor may it be copied in any way. If received in error, please contact
the company on 01234-791388, then delete it from your system. Please note
neither the company nor the sender accepts any responsibility for viruses
and it is your responsibility to scan attachments (if any) for viruses.
No contract may be concluded on behalf of the company by means of email
communications.
*************************************************************************************
MS Sql Server LazyDBA home page