#32593 [Opn->Fbk]: odbc with mysql SELECT with placeholders fails

2005-06-13 Thread sniper
 ID:   32593
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jake at edge2 dot net
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: *
 PHP Version:  5CVS, 4CVS (2005-04-14)
 New Comment:

Are you sure this isn't a bug with the Mysql ODBC driver?



Previous Comments:


[2005-04-13 17:33:40] jake at edge2 dot net

got a newer version of the tgz file this morning, built it successfully
(using ./configure --with-unixODBC=shared,/usr) and ran it like so:

[EMAIL PROTECTED] php4-STABLE-200504131242]$ php -dextension_dir=`pwd`/ext
~/x.php

and got exactly the same results as before (correct from pgsql, junk
(n_u nT0) from mysql)

I have also run into another problem, which may be related in that
php-odbc does not seem to do quoting correctly for placeholders for
either pgsql or mysql ... not sure if i should file a different bug or
add it to this one ... it also occurs on this version of php



[2005-04-07 17:51:12] [EMAIL PROTECTED]

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip





[2005-04-05 18:09:47] jake at edge2 dot net

Description:

If I use placeholders (?) in a SELECT statement using odbc_prepare()
and odbc_execute(), I get gibberish from the MySQL driver and it works
correctly using the PostgreSQL driver.

If I change the query to "WHERE id=1", it works fine.  UPDATES using
placeholders work fine for MySQL.

I am able to do the same queries in C using the same libraries for
unixODBC and MyODBC (and postgres-odbc) and get correct results.  This
may not be a PHP and/or PHP-odbc problem, but so far, it looks that
way.

I get substantially the same results on an FC3 and a RH9 linux box with
the following versions:

FC3:  php-4.3.10-3.2, php-odbc-4.3.10-3.2, unixODBC-2.2.9-1,
MyODBC-2.50.39-19.1, mysql-3.23.58-14

RH9:  php-4.2.2-17, php-odbc-4.2.2-17, unixODBC-2.2.3-6,
MyODBC-2.50.39-11, mysql-3.23.54a-11


Reproduce code:
---
#!/usr/bin/php



Expected result:

I expect to get the firstname and lastname from the database.  The
table is an int id and varchar(20) for the names.

Actual result:
--
Some kind of junk:  "std n_u"

Postgres gives the correct result (firstname and lastname from the
database)





-- 
Edit this bug report at http://bugs.php.net/?id=32593&edit=1


#32593 [Opn->Fbk]: odbc with mysql SELECT with placeholders fails

2005-04-07 Thread sniper
 ID:   32593
 Updated by:   [EMAIL PROTECTED]
 Reported By:  jake at edge2 dot net
-Status:   Open
+Status:   Feedback
 Bug Type: ODBC related
 Operating System: linux (fc3 and rh9)
 PHP Version:  4.3.10
 New Comment:

Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip




Previous Comments:


[2005-04-05 18:09:47] jake at edge2 dot net

Description:

If I use placeholders (?) in a SELECT statement using odbc_prepare()
and odbc_execute(), I get gibberish from the MySQL driver and it works
correctly using the PostgreSQL driver.

If I change the query to "WHERE id=1", it works fine.  UPDATES using
placeholders work fine for MySQL.

I am able to do the same queries in C using the same libraries for
unixODBC and MyODBC (and postgres-odbc) and get correct results.  This
may not be a PHP and/or PHP-odbc problem, but so far, it looks that
way.

I get substantially the same results on an FC3 and a RH9 linux box with
the following versions:

FC3:  php-4.3.10-3.2, php-odbc-4.3.10-3.2, unixODBC-2.2.9-1,
MyODBC-2.50.39-19.1, mysql-3.23.58-14

RH9:  php-4.2.2-17, php-odbc-4.2.2-17, unixODBC-2.2.3-6,
MyODBC-2.50.39-11, mysql-3.23.54a-11


Reproduce code:
---
#!/usr/bin/php



Expected result:

I expect to get the firstname and lastname from the database.  The
table is an int id and varchar(20) for the names.

Actual result:
--
Some kind of junk:  "std n_u"

Postgres gives the correct result (firstname and lastname from the
database)





-- 
Edit this bug report at http://bugs.php.net/?id=32593&edit=1