• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1734
  • Last Modified:

Ctreating temp table inside Exec command.

Hai frnds,

I have used the temp table inside my Exec statement. And If I tried to re use that temp table after Exec,it gave error as #output1 (this is name of temp table) not found .

What is the solution for this.
I need to use Exec coz I need to create a dynamic query depending on the input.

Please help me on this.

My proc is as below

create procedure ParentTest1
@whereClause varchar(100)

@sql varchar(1000)

      select @sql = "SELECT od.orderID orderDetailID,o.parentOrderID tmpParentOrderID ,o.orderID,
      INTO #output1
      FROM tmpOrders o, tmpOrderDetail od
      WHERE o.orderID *= od.orderID"+@whereClause
      select * from #output1

I think life of #output1 will end as soon as we complete Exec . Is this rt? Do u guys have any other solutions?

Thanks a lot for ur suggestion.

1 Solution
That is right, an EXEC is essentially a new connection to ASE and the temp table only exists within that scope (nor can the EXEC reference temp tables created outside of it's own scope).

The general solution is to create a permanent table to pass info through.  You can provide a key value in the string you pass to exec (such as the caller's @@spid value) that is inserted as a column value in the permanent table so the caller can identify their own rows.

General flow:

create table results (spid int, result int)

-- get rid of any old data in the table
delete results where spid = @@spid
-- call the exec that stores values
-- in the results table
exec (
            "insert results values ("
         + str(@@spid,10,0)
         + ", 42)"

select * from results where spid = @@spid

raghava_dgAuthor Commented:
thanks bret ,

but my worry in the above suggestion is .... I need to have a separate routine to purge the tmp table.
Because i will be passing "spid " after generating it by randaom genarator from my client. So each time it will be diffrent and the delete statement in my proc will not be of much help , I mean since each time new "spid " will be passed so i may not be able to delete it.

For my another technical reason due to the Java client I can not delete those records after i finesh my proceesing inside my proc coz last statement in my proc should return a resultset (i,e a select statement).
Please maintain open questions.

Free Tool: Port Scanner

Check which ports are open to the outside world. Helps make sure that your firewall rules are working as intended.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Well, that is one reason why I use the actual spid of the user process; it is easy to tell going in that if there is existing data with my own spid that it can be deleted.  (For that matter, any rows with a spid that is not currently in sysprocesses could also be deleted).

Perhaps your sproc could do this, which would both delete the records and allow the last statement to be the result set.  The temp table will automatically be cleaned up by ASE when the procedure exits.

select * into #temp from results where spid = @@spid
delete results where spid = @@spid
select * from #temp
raghava_dgAuthor Commented:
Thanks bret .
One more solution is to create the temp table out side ASE and use that #temp table inside ASE. Once sp is finished temp table will be deleted automatically.

Thanks for the help
Another way to do it is by chainning the commands, I used it  before several times and it works great :-)

declare @sql_text varchar(255)

select @sql = "SELECT od.orderID orderDetailID,o.parentOrderID tmpParentOrderID ,o.orderID,
     INTO #output1
     FROM tmpOrders o, tmpOrderDetail od
     WHERE o.orderID *= od.orderID"+@whereClause

select @sql_text = "select * from #output1"    

exec(@sql + @sql_text)

good luck.

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now