Re: Temporary table lifespan - SOLVED

2007-02-17 Thread Amer Neely

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:[EMAIL PROTECTED]
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!

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



RE: Temporary table lifespan - SOLVED

2007-02-16 Thread Jerry Schwartz
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:[EMAIL PROTECTED]
 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.

 --
 Amer Neely
 w: www.softouch.on.ca/
 b: www.softouch.on.ca/blog/
 Perl | MySQL programming for all data entry forms.
 We make web sites work!

 --
 MySQL General Mailing List
 For list archives: http://lists.mysql.com/mysql
 To unsubscribe:
 http://lists.mysql.com/[EMAIL PROTECTED]






-- 
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Temporary table lifespan

2007-02-15 Thread Amer Neely
I'm writing a perl script in which I need to save some session data. My 
first attempt is to use a temporary table to store some data.


However, I'm a little unclear as to the lifespan of the temporary table. 
My understanding is they last until the session ends, or a DELETE TABLE 
is issued. My question is 'what is a session'?


For example, in my perl script I create and populate the table in one 
subroutine, but need to access it from another in the same script. But 
it doesn't appear to live through the transition from one subroutine to 
another.


Anyone have an idea whether this can even be done, or does calling 
another subroutine end the 'session', thus killing the table?

--
Amer Neely
w: www.softouch.on.ca/
b: www.softouch.on.ca/blog/
Perl | MySQL programming for all data entry forms.
We make web sites work!

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Temporary table lifespan

2007-02-15 Thread Daniel Kasak

Amer Neely wrote:

I'm writing a perl script in which I need to save some session data. 
My first attempt is to use a temporary table to store some data.


However, I'm a little unclear as to the lifespan of the temporary 
table. My understanding is they last until the session ends, or a 
DELETE TABLE is issued. My question is 'what is a session'?


For example, in my perl script I create and populate the table in one 
subroutine, but need to access it from another in the same script. But 
it doesn't appear to live through the transition from one subroutine 
to another.


Anyone have an idea whether this can even be done, or does calling 
another subroutine end the 'session', thus killing the table?


Session isn't exactly the right word for it. The temporary tables hang 
around for the lifetime of the database connection. So if you open a 
database connection, make a tmp table, close the DB connection, and open 
another one ( inside the same subroutine ), your tmp table will be gone. 
Also, if you open 2 DB connections, and make a tmp table from one, the 
other connection can't see it. So just keep your DB connection ( or 
database handle in Perl speak ) live and you should be able to see the 
table.


--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [EMAIL PROTECTED]
website: http://www.nusconsulting.com.au

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Temporary table lifespan

2007-02-15 Thread Amer Neely

Amer Neely wrote:

Daniel Kasak wrote:

Amer Neely wrote:

I'm writing a perl script in which I need to save some session data. 
My first attempt is to use a temporary table to store some data.


However, I'm a little unclear as to the lifespan of the temporary 
table. My understanding is they last until the session ends, or a 
DELETE TABLE is issued. My question is 'what is a session'?


For example, in my perl script I create and populate the table in one 
subroutine, but need to access it from another in the same script. 
But it doesn't appear to live through the transition from one 
subroutine to another.


Anyone have an idea whether this can even be done, or does calling 
another subroutine end the 'session', thus killing the table?


Session isn't exactly the right word for it. The temporary tables hang 
around for the lifetime of the database connection. So if you open a 
database connection, make a tmp table, close the DB connection, and 
open another one ( inside the same subroutine ), your tmp table will 
be gone. Also, if you open 2 DB connections, and make a tmp table from 
one, the other connection can't see it. So just keep your DB 
connection ( or database handle in Perl speak ) live and you should be 
able to see the table.




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.





--
Amer Neely
w: www.softouch.on.ca/
b: www.softouch.on.ca/blog/
Perl | MySQL programming for all data entry forms.
We make web sites work!

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Temporary table lifespan

2007-02-15 Thread Daniel Kasak

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 ).


--
Daniel Kasak
IT Developer
NUS Consulting Group
Level 5, 77 Pacific Highway
North Sydney, NSW, Australia 2060
T: (+61) 2 9922-7676 / F: (+61) 2 9922 7989
email: [EMAIL PROTECTED]
website: http://www.nusconsulting.com.au

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Temporary table lifespan

2007-02-15 Thread Amer Neely

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.


--
Amer Neely
w: www.softouch.on.ca/
b: www.softouch.on.ca/blog/
Perl | MySQL programming for all data entry forms.
We make web sites work!

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]



Re: Temporary table lifespan - SOLVED

2007-02-15 Thread Amer Neely

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.


--
Amer Neely
w: www.softouch.on.ca/
b: www.softouch.on.ca/blog/
Perl | MySQL programming for all data entry forms.
We make web sites work!

--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe:http://lists.mysql.com/[EMAIL PROTECTED]