This is a two part question

1. when programming with ADO in C++, I close the connection with
m_pConn->Close();
m_pConn = NULL; // it's a member variable in a COM object.
Why does the temp table not DROP itself?
If I close the brower and reopen it, the table is still there!
(this object call a stored proc that builds the temp 'invoice_work').
I tried .Release and .Detach with resultant explosions.

If you think COM sucks and/or don't know or have any empathy, go to part 2.

2. How would I find out of the existance of the temp in this session so I
can
drop it myself?

sending to informix-list

1.
You may want to check and see if you are allowing for connection pooling. I
have had this experience (though rarely) with ADO/VB/ODBC in versions of the
client SDK from 2.30 to 2.81. In my case I could not create the temp table
because I would get an error saying that it exists, but oddly enough if I
tried to drop the temp table it would generate an error saying that it does
*not* exist!

2.
You can detect the temp by querying sysmaster:systabnames, but if you are
experiencing an issue similar to what I described above, you may not be able
to drop it anyway. If you are unable to arrive at a solution, one
workaround would be to generate a unique temp table name.

Good luck!

-Brian


"Bill Hamilton" <laidback (AT) finsco (DOT) com> wrote