bug with statement TYPE attribute?

bug with statement TYPE attribute?

am 16.03.2005 17:49:04 von Ray Zimmerman

I need some help with a hard-to-locate (for me) bug. After some major
upgrades of OS, perl, apache, etc a mod_perl app that worked fine
before began complaining that "You have an error in your SQL syntax". I
found it was due to incorrect quoting based on incorrect mysql column
types returned by DBI/DBD::mysql. Strangely, a stand-alone script
returns the correct column types, but the same script executed by
mod_perl gives incorrect types. I should mention that aside from this I
haven't noticed any other problems with the mod_perl installation.

Here are the details ...

Environment:
perl-5.8.6
apache-1.3.33
mod_perl-1.29
Linux 2.6.9 (RHEL 4 WS) Intel
DBI-1.48 (also tried 1.45, 1.47)
DBD-mysql-2.9004
connecting to:
mysql-4.0.16 (running on a different Intel Linux box)

----------------------
the script
----------------------
use strict;
use DBI;

my $DBI_DSN = 'DBI:mysql:database=MyDb;mysql_client_found_rows=0';
my $DBI_USER = 'MyUser';
my $DBI_PASS = 'MyPassword';
my $DBI_OPT = { PrintError => 0, RaiseError => 1, AutoCommit => 1 };
my $dbh = DBI->connect( $DBI_DSN, $DBI_USER, $DBI_PASS, $DBI_OPT );
my $sql = 'SELECT * FROM C_Object WHERE 1 = 0';
my $sth = $dbh->prepare( $sql );
my $rv = $sth->execute;
my $fields = $sth->{NAME};
my $types = $sth->{TYPE};
my $old_types = $sth->{mysql_type};

print "\ncol_name col_type old_type\n";
print "-------- -------- --------\n";
foreach (0..$#{$fields}) {
printf("%8s %5d %5d\n", $fields->[$_], $types->[$_],
$old_types->[$_]);
}
print "\n";
----------------------


----------------------
the table
----------------------
CREATE TABLE C_Object (
id int(11) NOT NULL auto_increment,
class char(255) default NULL,
created timestamp(14) NOT NULL,
PRIMARY KEY (id)
) TYPE=MyISAM;
----------------------


----------------------
the results
----------------------
If I run the script from the command line, I get the correct types for
each field ...

col_name col_type old_type
-------- -------- --------
id 4 3
class 1 254
created 11 7


If I run it via a PerlRequire in httpd.conf, I get incorrect field
types ...

col_name col_type old_type
-------- -------- --------
id 11 7
class 3 0
created 12 115

----------------------

I verified that @INC is the same, perl, DBI and DBD::mysql versions
being used are the same. I have two other machines which I recently
upgraded to the same versions of perl, apache, mod_perl and all Perl
modules. On my Mac OS X 10.3.8 machine things work fine, including
under mod_perl. On my older Linux box (Linux 2.2.22, RH 6.2), which is
the one running the mysql server, I get the correct types when run from
the command line, but when run from mod_perl as above, I get ...

col_name col_type old_type
-------- -------- --------
id 12 138876576
class 12 138876600
created 12 1952671082

All results are repeatable for me. So can anyone duplicate this? Have
any ideas where to go from here to try to track it down?

Ray Zimmerman
Director, Laboratory for Experimental Economics and Decision Research
428-B Phillips Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645


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

Re: bug with statement TYPE attribute?

am 16.03.2005 20:32:00 von Ray Zimmerman

Answering my own question ...

On Mar 16, 2005, at 11:49 AM, Ray Zimmerman wrote:
> I need some help with a hard-to-locate (for me) bug. After some major
> upgrades of OS, perl, apache, etc a mod_perl app that worked fine
> before began complaining that "You have an error in your SQL syntax".
> I found it was due to incorrect quoting based on incorrect mysql
> column types returned by DBI/DBD::mysql. Strangely, a stand-alone
> script returns the correct column types, but the same script executed
> by mod_perl gives incorrect types. I should mention that aside from
> this I haven't noticed any other problems with the mod_perl
> installation.

Aaargh! I finally found it ... one of the nastiest "gotchas" I've been
bitten by in a while.

It was because DBD::mysql will happily use mysql client routines
residing in libphp4.so !!! I had built the PHP4 module with mysql
support, which by default uses the mysql client libraries (3.23.49) in
the php distribution. But DBD::mysql was built using the system mysql
libraries (4.1.7). Since the libphp4.so was loaded before the Perl
stuff it used the wrong library. Getting rid of PHP or forcing it to
load later fixed the problem. I assume building it with the system
mysql client libraries should do the trick as well.

That'll teach me!

Ray Zimmerman
Director, Laboratory for Experimental Economics and Decision Research
428-B Phillips Hall, Cornell University, Ithaca, NY 14853
phone: (607) 255-9645


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

Re: bug with statement TYPE attribute?

am 16.03.2005 20:34:40 von Sean Quinlan

--=-dU/Q1SRmu4mWjn+Kti1c
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

WOW! Thanks for posting that. Knowing to check for library conflicts
like that under mod_perl could save me a lot of time some day!

On Wed, 2005-03-16 at 14:32 -0500, Ray Zimmerman wrote:
> Answering my own question ...
>=20
> On Mar 16, 2005, at 11:49 AM, Ray Zimmerman wrote:
> > I need some help with a hard-to-locate (for me) bug. After some major=20
> > upgrades of OS, perl, apache, etc a mod_perl app that worked fine=20
> > before began complaining that "You have an error in your SQL syntax".=20
> > I found it was due to incorrect quoting based on incorrect mysql=20
> > column types returned by DBI/DBD::mysql. Strangely, a stand-alone=20
> > script returns the correct column types, but the same script executed=20
> > by mod_perl gives incorrect types. I should mention that aside from=20
> > this I haven't noticed any other problems with the mod_perl=20
> > installation.
>=20
> Aaargh! I finally found it ... one of the nastiest "gotchas" I've been=20
> bitten by in a while.
>=20
> It was because DBD::mysql will happily use mysql client routines=20
> residing in libphp4.so !!! I had built the PHP4 module with mysql=20
> support, which by default uses the mysql client libraries (3.23.49) in=20
> the php distribution. But DBD::mysql was built using the system mysql=20
> libraries (4.1.7). Since the libphp4.so was loaded before the Perl=20
> stuff it used the wrong library. Getting rid of PHP or forcing it to=20
> load later fixed the problem. I assume building it with the system=20
> mysql client libraries should do the trick as well.
>=20
> That'll teach me!
>=20
> Ray Zimmerman
> Director, Laboratory for Experimental Economics and Decision Research
> 428-B Phillips Hall, Cornell University, Ithaca, NY 14853
> phone: (607) 255-9645
>=20
>=20
--=20

--=-dU/Q1SRmu4mWjn+Kti1c
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQBCOIpQnv2yYfTgGZsRAvV6AJ0eXVXnfKw/hwxBUWL3HVu+LW054wCf dhvp
RDt3OpqFLL5MFz1iD7xSGVw=
=5/U4
-----END PGP SIGNATURE-----

--=-dU/Q1SRmu4mWjn+Kti1c--