Jerry Schwartz wrote:
> Possibly you are opening another connection, using the same handle, when you
> re-enter your script. If that is the case, you'll lose track of your
> previous connection (the one that has the temporary table). You might also
> be accumulating a lot of connections, if this recursion happens multiple
> levels.
>
> Regards,
>
> Jerry Schwartz
> Global Information Incorporated
> 195 Farmington Ave.
> Farmington, CT 06032
>
> 860.674.8796 / FAX: 860.674.8341
>
>
>> -----Original Message-----
>> From: Amer Neely [mailto:trudge@softouch.on.ca]
>> Sent: Thursday, February 15, 2007 11:21 PM
>> To: Daniel Kasak; mysql@lists.mysql.com
>> Subject: Re: Temporary table lifespan - SOLVED
>>
>> Amer Neely wrote:
>>> Daniel Kasak wrote:
>>>> Amer Neely wrote:
>>>>
>>>>>> OK, that makes sense. As far as I know, my connection is
>> still live
>>>>>> - I don't do a disconnect anywhere. So I'm still not sure why I
>>>>>> can't pull the data back out. I do get an error telling
>> me about a
>>>>>> problem with my statement near .... which is where it tries to
>>>>>> execute the FROM command.
>>>>>> My apologies, I'm not on the computer that I am developing this
>>>>>> script on, so can't give you the exact error.
>>>>>>
>>>>>> I'm naming the table from a purchase order number, and
>> as far as I
>>>>>> can tell, the table I try to read from is the same as the one I
>>>>>> created - but I get nothing out of it.
>>>> It's hard to say without more details. You can send the
>> script if you
>>>> want. Also keep in mind that since you're using tmp tables
>> which are
>>>> invisible to all other connections, you don't need to much
>> around with
>>>> creating a unique table name - you can just use a generic one ( eg
>>>> tmp_purchase_order or something ).
>>>>
>>> I'll try something like that tomorrow. Thanks for the
>> responses. I'll
>>> post my results.
>>>
>> After failing to get the temporary table method working, I
>> ended up just
>> creating a table, then dropping it when I was done.
>>
>> It seems that a temporary table will get deleted when a script calls
>> itself and jumps to a function inside. That must constitute a
>> disconnection.

I checked my code, and one of the first things the script does is
connect to the database. So you're right, it starts a new connection. I
couldn't figure an easy way around that - kind of like the horse / cart
thingy, so went the route I did with just dropping a table after
processing. Works fine.
--
Amer Neely
w: www.softouch.on.ca/
b: www.softouch.on.ca/blog/
v: 705.223.3539
Perl | MySQL programming for all data entry forms.
"We make web sites work!"