Problem on Installing DBD::mysql module

I use Redhat 9.0 (kernal 2.4.20-8smp) on i686 PC,
mysql-2.4.0.2, perl 5.8.0, apache 2.0.48. Mysql is
installed on /mysqld directory with raid 1 enabled on
this directory.

I did:

perl Makefile.PL -cflags=-I/mysqld/include/mysql
"--libs=-L/mysqld/lib/mysql"

to complie the module and get:

Can't exec "mysql_config": No such file or directory
at Makefile.PL line 174.
readline() on closed filehandle PIPE at Makefile.PL
line 176.
Can't exec "mysql_config": No such file or directory
at Makefile.PL line 174.
readline() on closed filehandle PIPE at Makefile.PL
line 176.
Can't exec "mysql_config": No such file or directory
at Makefile.PL line 174.
readline() on closed filehandle PIPE at Makefile.PL
line 176.
Can't exec "mysql_config": No such file or directory
at Makefile.PL line 174.
readline() on closed filehandle PIPE at Makefile.PL
line 176.
Can't exec "mysql_config": No such file or directory
at Makefile.PL line 174.

Re: Problem on Installing DBD::mysql module

Make sure the mysql bin directory (probably /mysqld/bin/) is in your 
path.

On Sep 3, 2004, at 4:10 AM, So Wing Kei wrote:

> I use Redhat 9.0 (kernal 2.4.20-8smp) on i686 PC,
> mysql-2.4.0.2, perl 5.8.0, apache 2.0.48. Mysql is
> installed on /mysqld directory with raid 1 enabled on
> this directory.
>
> I did:
>
> perl Makefile.PL -cflags=-I/mysqld/include/mysql
> "--libs=-L/mysqld/lib/mysql"
>
> to complie the module and get:
>
> Can't exec "mysql_config": No such file or directory
> at Makefile.PL line 174.
> readline() on closed filehandle PIPE at Makefile.PL
> line 176.
> Can't exec "mysql_config": No such file or directory
> at Makefile.PL line 174.
> readline() on closed filehandle PIPE at Makefile.PL
> line 176.
> Can't exec "mysql_config": No such file or directory
> at Makefile.PL line 174.
> readline() on closed filehandle PIPE at Makefile.PL
> line 176.
> Can't exec "mysql_config": No such file or directory

Re: Problem on Installing DBD::mysql module

unset LANG then compile.

Rudy

On Fri, 3 Sep 2004, So Wing Kei wrote:

> Date: Fri, 3 Sep 2004 04:10:48 -0700 (PDT)
> From: So Wing Kei <kenny_sos <at> yahoo.com.hk>
> To: msql-mysql-modules <at> lists.mysql.com
> Subject: Problem on Installing DBD::mysql module
> 
> I use Redhat 9.0 (kernal 2.4.20-8smp) on i686 PC,
> mysql-2.4.0.2, perl 5.8.0, apache 2.0.48. Mysql is
> installed on /mysqld directory with raid 1 enabled on
> this directory.
> 
> I did:
> 
> perl Makefile.PL -cflags=-I/mysqld/include/mysql
> "--libs=-L/mysqld/lib/mysql"
> 
> to complie the module and get:
> 
> Can't exec "mysql_config": No such file or directory
> at Makefile.PL line 174.
> readline() on closed filehandle PIPE at Makefile.PL
> line 176.
> Can't exec "mysql_config": No such file or directory
> at Makefile.PL line 174.

Announcement: prepared statement and embedded server support on Dev-2_9 CVS

Hello Users/Developers,

I have just committed support for prepared statements and MySQL  
embedded server support to CVS development branch Dev-2_9 (based off of  
2.900x code) for DBD::mysql. You can get this code to try out via:

cvs -d :pserver:anonymous <at> cvs.perl.org:/cvs/public login
cvs -d :pserver:anonymous <at> cvs.perl.org:/cvs/public co -rDev-2_9  
modules/DBD-mysql

To use server side prepare statements, all you really need to do is set  
the value "mysql_server_prepare" in the connect string:

my $dbh =  
DBI->connect("DBI:mysql:database=test;host=localhost: 
mysql_server_prepare=1", "","");

When you build DBD::mysql and run make test, after you first test  
without server side prepare statements, you can test with by exporting  
the environment variable MYSQL_SERVER_PREPARE

export MYSQL_SERVER_PREPARE=1

and then run 'make test' again. This stage will be improved in the  
future.

Also, for information about using the embedded server, please read the  
pod documentation found in the perl module itself.

For more information about prepared statements and how you can take  

Automatically re-connecting to the database.

Tim &al,

DBD::mysql has had the ability to automatically reconnect to the server in the
event that the server closed the connection to the client. This is useful in the
event of timeouts in a mod_perl environment, so you can just connect to the
database and not have to worry about how long the connection was idle because
the client will automatically reconnect to the server in the event of a timeout.
It is also useful in the case where a query or an insert exceeds the max allowed
packet size, for if a statement exceeds max allowed packet, the server will
close the connection on you.

The problem arises when you have temp tables or prepared statements. The two
major cases (that I can think of) where autoreconnect can cause problems are
with the auto_reconnect attribute and with ping.

first, for the the $dbh->{mysql_auto_reconnect} attribute:

Consider this:

    my $sth = $dbh->prepare($some_statement); # server-side woohoo!
    $sth1->execute($max_packet_size." "); # db gone away.
    $dbh->do(q{SELECT 1});  #reconnects to the db.
    $sth->execute();  # oops no prepared statement.

So do we say that mysql_auto_reconnect will be disabled when server-side
prepared statements are in use? Do we keep a list of prepared statements and
"un-prepare" them on re-connect and re-prepare them when used or re-prepare on
reconnect?

Re: Automatically re-connecting to the database.

Rudy, --

my two cents on this,

On Mon, Sep 06, 2004 at 02:01:07PM -0400, Rudy Lippan wrote:
> DBD::mysql has had the ability to automatically reconnect to the server in the
> event that the server closed the connection to the client. This is useful in the
> event of timeouts in a mod_perl environment, so you can just connect to the

In mod_perl environment auto-reconnect is rather evil then useful,

> The problem arises when you have temp tables or prepared statements. The two

it also breaks whole session-depended environment, such as
user  <at> variables, established locks, and (possible) semaphores, ...

Only application has benefits from auto-reconnect I could see
is interactive one, similar to mysql command-line client,
where human can decide what to do next.

Other then that, disconnect should throw red flag to apps
to re-establish lots of program context, so
non-interactive apps (including cgi-s) should not rely
on this feature, and have to keep it disabled.

--w

--

-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl

Re: Automatically re-connecting to the database.

On Mon, Sep 06, 2004 at 02:01:07PM -0400, Rudy Lippan wrote:
> 
> Tim &al,
> 
> DBD::mysql has had the ability to automatically reconnect to the server in the
> event that the server closed the connection to the client. This is useful in the
> event of timeouts in a mod_perl environment, so you can just connect to the
> database and not have to worry about how long the connection was idle because
> the client will automatically reconnect to the server in the event of a timeout.
> It is also useful in the case where a query or an insert exceeds the max allowed
> packet size, for if a statement exceeds max allowed packet, the server will
> close the connection on you.
> 
> The problem arises when you have temp tables or prepared statements. The two
> major cases (that I can think of) where autoreconnect can cause problems are
> with the auto_reconnect attribute and with ping.

> first, for the the $dbh->{mysql_auto_reconnect} attribute:
> 
> Consider this:
> 
>     my $sth = $dbh->prepare($some_statement); # server-side woohoo!
>     $sth1->execute($max_packet_size." "); # db gone away.
>     $dbh->do(q{SELECT 1});  #reconnects to the db.
>     $sth->execute();  # oops no prepared statement.
> 
> So do we say that mysql_auto_reconnect will be disabled when server-side
> prepared statements are in use?

Yes. That's what I'd recommend. Personally I'd disable it by default

Re: Automatically re-connecting to the database.

On Mon, 6 Sep 2004, Tim Bunce wrote:

> > So do we say that mysql_auto_reconnect will be disabled when server-side
> > prepared statements are in use?
> 
> Yes. That's what I'd recommend. Personally I'd disable it by default
> and make applications ask for it explicitly if they want it.
> It's just not safe enough to leave on.

Ok. Easy enough. Right now it is only defaulting to on when it sees 
$ENV{GATEWAY_INTERFACE} || $ENV{MOD_PERL}, so I will not turn it on when 
serverside-prepare is true.

> > DBD::mysql's ping function uses the mysql API function mysql_ping() which will,
> > in the event that the server closed the connection, automatically reconnect to
> > the server and returns TRUE.
> 
> http://bugs.mysql.com/bug.php?id=2532

Ah, IC.

> I think $dbh->ping should return false if the connection-id (thread-id)
> changes.
> 
> (Perhaps return "0", rather than "" or undef, in this case.)
>

That sounds good, so I'll do that.  It is not 100%, but should work.

> > And then there is the case of backwards compatibility. How many applications

Use one variable for multiple binds

I dont know if this is possible.
when calling execute with one variable that holds multiple placeholders.

Similar to this.
$dbh->execute($variable)
the $variable holds multiple values ie..
$variable="bindinfo1,bindinfo2"

My problem is mysql expects 2 bind variables ie.. $dbh->execute($variable1,$variable2)

I am trying to select when not knowing the number of requisites.

Hoping is something small I am overlooking.

Thank you for any help you can give me
Arthur

--

-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe:    http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules <at> m.gmane.org

Re: Use one variable for multiple binds

Newbedford.net wrote:
> I dont know if this is possible.
> when calling execute with one variable that holds multiple placeholders.
> 
> Similar to this.
> $dbh->execute($variable)
> the $variable holds multiple values ie..
> $variable="bindinfo1,bindinfo2"

Hopefully, this will never be the case. IMO, it is completely up to you, 
to implement the logic, if, and when, to apply something as simple as

   my  <at> vars;
   if (hasMultipleVars($variable)) {
	 <at> vars = split(/,/, $variable);
   } else {
	 <at> vars = ($variable);
   }

If you disagree, I'd be interested to learn, how you suggest the drivers
implementation of hasMultipleVars($variable).

Jochen

-- 
http://lilypie.com/baby1/050423/1/5/1/+1

--

-- 
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl