multiple simultaneous DBI connections?

2003-03-13 Thread Tom Norwood
I am currently looking at building a Perl object to handle data from a
a database.
I'm not really sure if it is best to have one connection to MySQL and
let the object just deal with its own properties.
Or to allow the object to initiate a DBI connection each time an instance
of the object is created, and to disconnect() using garbage disposal.

Although the object initially would only have one instance per script,
I can't help feeling it is a bad idea.

Any thoughts welcome, and greatly appreciated,
Tom Norwood.



This email has been scanned for viruses by NetBenefit using Sophos anti-virus 
technology



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php



RE: multiple simultaneous DBI connections?

2003-03-13 Thread Tom Norwood
Paul,
I guess I would see the fact that the script would hold the connection
to MySQL for a shorter period of time, as the most obvious advantage.

As far as OO programming goes the integration of DBI into my object
would assure that a connection to the database would be established
automatically before the object's methods try to initiate calls to the
MySQL server.
Also a similar point goes for disconnect()-ing from the server, my
object would 'know' that a connection is available if it exists! So no
additional coding would be required within my object's methods.

Tom Norwood.

-Original Message-
From: Paul DuBois [mailto:[EMAIL PROTECTED]
Sent: 13 March 2003 15:14
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: multiple simultaneous DBI connections?


At 14:47 + 3/13/03, Tom Norwood wrote:
I am currently looking at building a Perl object to handle data from a
a database.
I'm not really sure if it is best to have one connection to MySQL and
let the object just deal with its own properties.
Or to allow the object to initiate a DBI connection each time an instance
of the object is created, and to disconnect() using garbage disposal.

Although the object initially would only have one instance per script,
I can't help feeling it is a bad idea.

It's difficult to give you an answer each way unless you tell us why
you suspect it might be a bad idea.  Certainly you'll use somewhat
more resources on both the client and server ends if you maintain
multiple open connections.  What would you see as an advantage to
having multiple connections?


Any thoughts welcome, and greatly appreciated,
Tom Norwood.



This email has been scanned for viruses by NetBenefit using Sophos
anti-virus technology




This email has been scanned for viruses by NetBenefit using Sophos anti-virus 
technology



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php



RE: multiple simultaneous DIB connections?

2003-03-13 Thread Tom Norwood
Although my initial implementation would only deal with one instance
of my object.
There WOULD be simultaneous connections if two or more instances of my
object existed at the same time.

Tom Norwood.

-Original Message-
From: Paul DuBois [mailto:[EMAIL PROTECTED]
Sent: 13 March 2003 16:23
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: multiple simultaneous DBI connections?


At 15:47 + 3/13/03, Tom Norwood wrote:
Paul,
I guess I would see the fact that the script would hold the connection
to MySQL for a shorter period of time, as the most obvious advantage.

As far as OO programming goes the integration of DBI into my object
would assure that a connection to the database would be established
automatically before the object's methods try to initiate calls to the
MySQL server.
Also a similar point goes for disconnect()-ing from the server, my
object would 'know' that a connection is available if it exists! So no
additional coding would be required within my object's methods.

Tom Norwood.

Ah.  I was misinterpreting your message, thinking you meant multiple
*simultaneous* connections.

With some database engines, you'd probably want to use a single
connection and hold it open, because the overhead for connection
setup/teardown is significant.

With MySQL, that's not much of a factor in most cases.  It has
very efficient connection establishment.


-Original Message-
From: Paul DuBois [mailto:[EMAIL PROTECTED]
Sent: 13 March 2003 15:14
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: multiple simultaneous DBI connections?


At 14:47 + 3/13/03, Tom Norwood wrote:
I am currently looking at building a Perl object to handle data from a
a database.
I'm not really sure if it is best to have one connection to MySQL and
let the object just deal with its own properties.
Or to allow the object to initiate a DBI connection each time an instance
of the object is created, and to disconnect() using garbage disposal.

Although the object initially would only have one instance per script,
I can't help feeling it is a bad idea.

It's difficult to give you an answer each way unless you tell us why
you suspect it might be a bad idea.  Certainly you'll use somewhat
more resources on both the client and server ends if you maintain
multiple open connections.  What would you see as an advantage to
having multiple connections?


Any thoughts welcome, and greatly appreciated,
  Tom Norwood.



This email has been scanned for viruses by NetBenefit using Sophos
anti-virus technology




This email has been scanned for viruses by NetBenefit using Sophos anti-virus 
technology



-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php



Another 'Too many connections' question...

2002-08-21 Thread Tom Norwood

A couple of weeks ago I came across this error which effectively closed down
our site.

Two things:
(1) I am using Perl DBI to interface mySQL is there any way to effectively
capture such errors and provide an alternate web page?  I guess there has to
be, but I experimented with the 'PrintError' and 'RaiseError' with little
joy.

(2) At present our MySQL needs are provided by our ISP by means of a shared
server (dedicated to MySQL I think!).  The 'max_connections' variable (SHOW
VARIABLES) is currently set to 300, which seems a bit on low side for a
server with 770 databases (SHOW DATABASES) with I don't know how many
tables.
What causes this error, 'any' connection, admin type connections, etc.?
And does this error require a server/mysqld restart on the part of our ISP?
They were typically unhelpful when I spoke to them (hope that's not due to
ignorance.)

Have been looking at dedicated hosting for a while now, but finding the cash
and moreover the time to move is proving a slow process.

Any help gratefully Rx'd,
Tom.


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




Date Comparison Problem...

2002-07-27 Thread Tom Norwood

Just when I thought I was getting the hang of this mysql stuff, the simplest
of tasks
is causing me to think about pulling my hair out.

My table:

   NEWS {
 newsID (INT(3), AUTO-INCREMENT),
 newsTitle (VARCHAR (50)),
 newsText (BLOB),
 newsDate (DATE)
   }

I just want to filter OUT any rows that have a 'future' date value in
'newsDate' column.
(ie. Don't select any news that hasn't happened yet!)

Query, I gather the WHERE clause deals with -MM-DD formatted dates:

   SELECT * FROM news
 WHERE newsDate  DATE_ADD(CUR_DATE(), INTERVAL 1 DAY)
 ORDER BY newsDate DESC

If I take out the WHERE clause the whole table gets SELECT-ed, it works
fine:

   SELECT * FROM news
 ORDER BY newsDate DESC

Any assistance gratefully Rx'd.  I have DuBois's MySQL, it's obviously too
good for me.
Also tried various searches on MySQL.com, with little joy, aahh!

Tom.


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php




ADD: Date Comparison Problem...

2002-07-27 Thread Tom Norwood

Very interesting addition to message...

Forgot to mention what the problem-query produces:  Nothing.

Cheers,
Tom.

-Original Message-
From: Tom Norwood [mailto:[EMAIL PROTECTED]]
Sent: 27 July 2002 19:39
To: mysql-list
Subject: Date Comparison Problem...


Just when I thought I was getting the hang of this mysql stuff, the simplest
of tasks
is causing me to think about pulling my hair out.

My table:

   NEWS {
 newsID (INT(3), AUTO-INCREMENT),
 newsTitle (VARCHAR (50)),
 newsText (BLOB),
 newsDate (DATE)
   }

I just want to filter OUT any rows that have a 'future' date value in
'newsDate' column.
(ie. Don't select any news that hasn't happened yet!)

Query, I gather the WHERE clause deals with -MM-DD formatted dates:

   SELECT * FROM news
 WHERE newsDate  DATE_ADD(CUR_DATE(), INTERVAL 1 DAY)
 ORDER BY newsDate DESC

If I take out the WHERE clause the whole table gets SELECT-ed, it works
fine:

   SELECT * FROM news
 ORDER BY newsDate DESC

Any assistance gratefully Rx'd.  I have DuBois's MySQL, it's obviously too
good for me.
Also tried various searches on MySQL.com, with little joy, aahh!

Tom.


-
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/   (the list archive)

To request this thread, e-mail [EMAIL PROTECTED]
To unsubscribe, e-mail [EMAIL PROTECTED]
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php