Bug #64852 [Asn]: Allow binding arrays in PDO
Edit report at https://bugs.php.net/bug.php?id=64852edit=1
ID: 64852
Updated by: w...@php.net
Reported by:vr...@php.net
Summary:Allow binding arrays in PDO
Status: Assigned
Type: Bug
Package:PDO related
Operating System: Any
PHP Version:5.5.0RC1
Assigned To:wez
Block user comment: N
Private report: N
New Comment:
It would be nice, but unfortunately it can't be done in a sane way at the PDO
level; there is no
consistent way to express how to handle data binding to array types and in the
absence of that, the
parameter binding needs to explicitly specify each parameter.
This would require a much more powerful SQL parsing layer to resolve and make
it work properly,
This sort of feature is better implemented in a layer on top of PDO.
Previous Comments:
[2013-05-16 05:23:12] vr...@php.net
Wez, do you think it's reasonable?
[2013-05-16 05:22:04] vr...@php.net
Description:
Binding arrays would be useful in these queries:
WHERE id IN ?
INSERT INTO ... VALUES ?
Most database systems don't support binding complex data structures on server
side but PDO supports client side data binding so it can expand arrays to
scalars and use them. Example:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE id IN ?);
$stmt-execute([ array('1', '2', '3') ]);
// This will be executed with client side data binding:
// SELECT * FROM table WHERE id IN ('1', '2', '3')
// With server side data binding:
// SELECT * FROM table WHERE id IN (?, ?, ?) -- bind values: '1', '2', '3'
?
It means that with server side data binding, arrays will be expanded to
variable number of placeholders and the elements in the array will be bound.
There is a risk that the same statement would be used with a differently
structured array or with non-array. Example:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE id IN ?);
// Expands query to: SELECT * FROM table WHERE id IN (?, ?, ?)
$stmt-execute([ array(1, 2, 3) ]);
// This subsequent call should throw.
$stmt-execute([ array(1, 2, 3, 4) ]);
// This subsequent call should also throw.
$stmt-execute([ 1 ]);
?
This is a very rare usage and throwing an error in this case seems like a good
solution.
=== Named parameters ===
Named parameters could expand to name-key pair:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE id IN :ids);
// Expands query to: SELECT * FROM table WHERE id IN (:ids_0, :ids_1, :ids_2)
$stmt-execute([ 'ids' = array(1, 2, 3) ]);
?
However, there could be a collision: WHERE id = :ids_0 OR id IN :ids. PDO
could solve it by some sort of escaping - e.g. by prepending a magic string to
all array names or by prepending something else also to all non-array names. Or
it could just throw as this would be a rare and easily fixable problem.
=== Nested arrays ===
Expanding arrays should be recursive to support these queries:
?php
$stmt = $pdo-prepare(SELECT * FROM table WHERE (type, type_id) IN ?);
// Expands to SELECT * FROM table WHERE (type, type_id) IN ((?, ?), (?, ?))
$types = array();
$types[] = array('article', 1);
$types[] = array('comment', 11);
$stmt-execute([ $types ]);
?
=== Braces or no braces ===
Array should expand to comma-delimited, braces-enclosed string. This expansion
would support queries WHERE (type, type_id) IN ?. It unfortunately wouldn't
support this query:
INSERT INTO ... VALUES (...), (...), ...
This query needs braces in inner array and no braces in outer array so there's
no consistent way to support this type of query.
=== Empty arrays ===
Empty arrays should be treated same as other arrays so they should expand to
(). INSERT INTO table () VALUES () is a valid query, at least in MySQL (it
inserts a row with all default values). This would cause a syntax error in
query WHERE id IN () but that's a good behavior as there's no way to tell
database to not match anything. WHERE id IN (NULL) would be a solution in
this particular query (as NULL doesn't equal to NULL) but WHERE id NOT IN
(NULL) wouldn't return NULL rows. So empty array must expand to ().
=== Debugging ===
PDO should disclose a method returning the real query sent to the server. It
would be useful even without arrays, especially with client-side binding.
=== Implementation ===
Implementation would be tricky as the statement couldn't be prepared until it's
executed. It means that PDO wouldn't talk to the database server in prepare()
even with server-side binding (this is the current behavior with client-side
binding). The query would be both prepared and executed in execute().
--
Edit this bug report at https://bugs.php.net/bug.php?id=64852edit=1
Bug #63347 [Asn-Nab]: Different behavior of parameters processing
Edit report at https://bugs.php.net/bug.php?id=63347edit=1
ID: 63347
Updated by: w...@php.net
Reported by:naquad at gmail dot com
Summary:Different behavior of parameters processing
-Status: Assigned
+Status: Not a bug
Type: Bug
Package:PDO related
Operating System: Linux
PHP Version:5.4.8
Assigned To:wez
Block user comment: N
Private report: N
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
We can't reimplement the mysql (or any DB) prepared statement support 100% on
the
client side. Emulated prepares behave differently and this is one of the ways
that this manifests. This behavior will not be changed. If it is important
for
you that this work both ways, then you should write your queries with emulated
prepares turned off.
Previous Comments:
[2012-10-25 10:15:28] naquad at gmail dot com
Its not bogus. You can change the query to something like 'insert into
users(login, password, screen_name) values(:login, :password, :login)' and
issue will be still ok. And if it is violated then why emulated prepares work
with this?
[2012-10-25 10:08:26] u...@php.net
I consider this bogus: SQL syntax violated. Mapping feature abused to create
dynamic SQL, which is against the main argument brought up for PDO's PS
fixation.
[2012-10-25 04:01:44] larue...@php.net
seems native prepare supporting doesn't supports multi-same-name params, it
will
faild in the params number checking
[2012-10-24 14:06:31] naquad at gmail dot com
Description:
PDO::ATTR_EMULATE_PREPARES changes behavior of parameter processing.
When it is enabled multiple occurrences of named parameter work as expected,
but
when it is disabled I get Invalid parameter number error.
Test script:
---
?php
$pdo = new PDO('mysql:host=localhost;dbname=test', 'root', '');
$pdo-setAttribute(PDO::ATTR_EMULATE_PREPARES, false); /// remove this line
and scirpt works as expected
$pdo-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$query = $pdo-prepare('select :x = :x');
$query-bindValue(':x', 1);
$query-execute();
$t = $query-fetch();
var_dump($t);
$query-closeCursor();
Expected result:
array(2) {
'\'1\' = \'1\'' =
string(1) 1
[0] =
string(1) 1
}
Actual result:
--
PDOException: SQLSTATE[HY093]: Invalid parameter number in
/srv/http/fucktube/app/test.php on line 7
Call Stack:
0.0002 230552 1. {main}() /srv/http/fucktube/app/test.php:0
0.0739 246416 2. PDOStatement-execute()
/srv/http/fucktube/app/test.php:7
--
Edit this bug report at https://bugs.php.net/bug.php?id=63347edit=1
Bug #53458 [Opn]: Non-linear performance degradation on certain prepared SELECT queries
Edit report at http://bugs.php.net/bug.php?id=53458edit=1
ID: 53458
Updated by: w...@php.net
Reported by:don at smugmug dot com
Summary:Non-linear performance degradation on certain
prepared SELECT queries
Status: Open
Type: Bug
Package:PDO related
Operating System: CentOS 5.5
PHP Version:5.3.3
Block user comment: N
Private report: N
New Comment:
from a twitter conversation with Don, the heart of this issue is that
the there
appears to be a difference in the performance of fetch() or fetchAll()
depending
on whether query() or prepare() + execute() were used.
Given that query() is really just prepare() + execute() under the
covers, it is
difficult to explain this difference.
Previous Comments:
[2010-12-03 03:36:14] don at smugmug dot com
FYI, setting PDO::MYSQL_ATTR_USE_BUFFERED_QUERY to true/false didn't
have a large impact. Still ~10X slower than any of the other methods
either way. (Buffered was slightly faster)
[2010-12-02 23:39:10] don at smugmug dot com
Here's my PHP build configuration:
'./configure' '--enable-exif' '--with-gd' '--enable-gd-native-ttf'
'--with-jpeg-
dir=/usr' '--with-png-dir=/usr' '--with-freetype-dir=/usr' '--with-zlib'
'--
enable-inline-optimization' '--with-bz2' '--with-apxs2' '--with-xmlrpc'
'--with-
curl' '--with-libdir=lib64' '--with-pdo-mysql=mysqlnd' '--with-mcrypt'
'--enable-
bcmath' '--with-gmp' '--enable-mbstring' '--with-mysql=mysqlnd'
'--with-openssl'
'--with-mysqli=mysqlnd'
[2010-12-02 23:29:50] don at smugmug dot com
Description:
When retrieving results from prepared PDO statements against MySQL, we
get
performance that diverges from expected by 10X or more on results as low
as 1
rows. This only occurs for 'SELECT ... WHERE Id IN ( .. )' queries.
The attached script provides two PDO prepared approaches
('row-prepared', default,
and 'all-prepared') as well as a variety of control methods that use
non-prepared
PDO queries, straight MySQL, and prepared queries using MySQLi. Only
PDO with
prepared queries exhibits the problem.
If the query is broken up into chunks that return 1000 rows or less
prior to
execution, then combined afterwards in PHP, performance is as expected.
Test script:
---
You can get the sample script from:
http://www.smugmug.com/test/pdo-problem.php.gz
Expected result:
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
should
return in ~0.5s, like the other types (row, all, chunk, mysql, mysqli).
Actual result:
--
pdo-problem.php?type=row-prepared and pdo-problem.php?type=all-prepared
return in
~6s instead of ~0.5s
--
Edit this bug report at http://bugs.php.net/bug.php?id=53458edit=1
#47984 [Asn-Opn]: COM automation: garbled utf-8 text
ID: 47984 Updated by: w...@php.net Reported By: js at mcs dot be -Status: Assigned +Status: Open Bug Type: COM related Operating System: Windows XP PHP Version: 5.2.9 Assigned To: wez Previous Comments: [2009-04-16 09:22:47] js at mcs dot be Description: When using the attached script (saved as UTF-8 without BOM) to generate a word document, at the end of the text typed programmatically into word a ÿ character gets added. This character is only visible if I press the inverted P button on the toolbar. This is a reduced test case, but in real-world scenarios, visibly garbled text is inserted into word. Reproduce code: --- ?php unlink(dirname(__FILE__).\\test.doc); $word = new COM(word.application, NULL, CP_UTF8); $word-Visible = false; // hidden $word-Documents-Add(); $word-Selection-TypeText(This is a tést...); $word-Documents[1]-SaveAs(dirname(__FILE__).\\test.doc); $word-Quit(); $word = null; header(Content-type: text/plain); echo wrote file to .dirname(__FILE__).\\test.doc; ? Expected result: The COM automation should accept UTF-8 formatted PHP strings without malforming the string ending when the CP_UTF8 parameter is added. Actual result: -- Broken characters at the end of every string containing non-ASCII characters sent via COM automation. -- Edit this bug report at http://bugs.php.net/?id=47984edit=1
#48061 [Asn-Opn]: Exception when passing array by ref to COM method
ID: 48061
Updated by: w...@php.net
Reported By: kmb at kai-m-becker dot de
-Status: Assigned
+Status: Open
Bug Type: COM related
Operating System: Windows XP SP3
PHP Version: 5.2.9
Assigned To: wez
Previous Comments:
[2009-04-23 13:43:07] kmb at kai-m-becker dot de
Description:
When calling a COM method with an array argument by reference, a
com_exception type mismatch is thrown.
Problem occurs only with arrays(!) as arg by ref.
Scalar types work fine as arg by ref.
php-5.2.9\ext\com_dotnet\com_com.c shows that the exception comes from
IDispatch_Invoke() (Windows-API) called in php_com_invoke_helper().
Reproduce code:
---
$opc = new COM('Matrikon.OPC.Automation'); // -- certified COM App
$opc-Connect('Matrikon.OPC.Simulation.1');
$opcgroup = $opc-OPCGroups-Add(mes);
// some code to fill $serverhandles
$values = array();
$errors = array();
$qualities = array();
$timestamps = array();
// function SyncRead( // acc. to com_print_typeinfo() and OPC-spec.
///* VT_I2 [2] [in] */ $Source,
///* VT_I4 [3] [in] */ $NumItems,
///* VT_PTR [26] [in] -- VT_SAFEARRAY [27] */ $ServerHandles,
///* VT_PTR [26] [out] -- VT_SAFEARRAY [27] */ $Values,
///* VT_PTR [26] [out] -- VT_SAFEARRAY [27] */ $Errors,
///* VT_PTR [26] [out] -- VT_VARIANT [12] */ $Qualities,
///* VT_PTR [26] [out] -- VT_VARIANT [12] */ $TimeStamps
//)
$opcgroup-SyncRead(
OPC_DS_CACHE, count($serverhandles), $serverhandles, // [in] args
$values, $errors, $qualities, $timestamps // [out] args
);
Expected result:
Successful call to SyncRead().
Actual result:
--
com_exception: Parameter 4: Typkonflikt (= type mismatch)
#0 opc_read_test.php(148): variant-SyncRead(1, 56, Array,
Object(variant), Object(variant), Object(variant), Object(variant))
#1 {main}
--
Edit this bug report at http://bugs.php.net/?id=48061edit=1
#27792 [Asn]: Functions fail on large files (filesize,is_file,is_dir)
ID: 27792
Updated by: [EMAIL PROTECTED]
Reported By: kode at kodekrash dot com
Status: Assigned
Bug Type: Filesystem function related
Operating System: * (LFS)
PHP Version: 6CVS, *CVS
Assigned To: wez
New Comment:
You might like to try the following patch:
http://news.php.net/php.internals/32767
Previous Comments:
[2007-08-17 09:36:22] aames at lycos dot de
Hello,
Using
--
if($file != '.' $file != '..' filetype($folderpath . '/' . $file)
== 'file' substr($file,0,1) != '.'){
$fileid = fileid($folderpath,$file);
$files[$file] = array($fileid,'exist');
}
--
To determine if a given filename is a file.
filetype() results in the already mentioned Errors for a file with 3.5
GB -- even on PHP Version 5.2.1
[2007-04-11 21:38:48] robertmcol at gmail dot com
Hi,
My OS information is
PHP Version 5.1.6
Apache/2.2.2 (Fedora)
Fedora Core 5 Kernel 2.6.20-1.2307.fc5
Is the issue with large files resolved ?
If not are there any expectations as to when it may get resolved ?
I have been trying to sort a problem displaying large files and dates
and have been getting invalid results.
[2006-12-27 20:36:37] bond00 at byu dot edu
I would love to know if this bug has indeed been fixed in 5.2. I tried
it in 5.2 and it didn't work, but someone mentioned that this could be
due to my 32 bit processor. Can anyone confirm this as well? Thanks!
[2006-12-18 03:09:08] judas dot iscariote at gmail dot com
This seems to work in 5.2.0 file_exists is returning
correct information on large files..
I dunno why this wasnt metioned in the Changelog.. nor if
the included solution is complete or partial.. can any dev
confirm this ?
[2006-12-05 18:49:33] eric dot gewirtz at solutiononecdi dot com
I was having issues with fopen() and files 2g. This is now working
for me in 5.2.0-7. I also tested the filesize() function with 5.2.0-7
and it still has an issue because it returns an int and the file size
2g blows but the error message is gone but it is clearly documented in
the online manual.
The following is from the manual;
Note: Because PHP's integer type is signed and many platforms use 32bit
integers, filesize() may return unexpected results for files which are
larger than 2GB. For files between 2GB and 4GB in size this can usually
be overcome by using sprintf(%u, filesize($file)).
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/27792
--
Edit this bug report at http://bugs.php.net/?id=27792edit=1
#42036 [Asn-Fbk]: fgetc() sets end of the file flag when reading on write only file
ID: 42036 Updated by: [EMAIL PROTECTED] Reported By: kraghuba at in dot ibm dot com -Status: Assigned +Status: Feedback Bug Type: Filesystem function related Operating System: RHEL 5 PHP Version: 5CVS-2007-07-18 (snap) Assigned To: wez New Comment: Without having had time to dig deeper just yet, if you open for write only, you shouldn't expect to be able to read. This application-level error is reflected as EOF. So the question becomes, is this behavior different from libc, and did the php behavior change between releases? (I'm not including PHP 6 in that, because it is not released yet) If the latter, we need to fix it, it not, we probably shouldn't fix it if there's a risk of breaking an app. I'm leaning towards won't fix; you should open the file as you intend to use it. Previous Comments: [2007-07-23 08:34:56] [EMAIL PROTECTED] Wez, could you plz comment this? [2007-07-21 05:55:08] kraghuba at in dot ibm dot com This defect is also applicable to the function fgets(). [2007-07-18 16:48:08] kraghuba at in dot ibm dot com Description: fgetc() sets the end of the file flag to ture when reading from a file which opened in write only mode. This failure is applicable on php5 and php6 php version: PHP 6.0.0-dev (cli) (built: Jul 18 2007 20:53:03) (GCOV) Copyright (c) 1997-2007 The PHP Group Zend Engine v3.0.0-dev, Copyright (c) 1998-2007 Zend Technologies PHP 5.2.4-dev (cli) (built: Jul 18 2007 20:49:53) (GCOV) Copyright (c) 1997-2007 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2007 Zend Technologies OS : RHEL 5 configure setup: ./configure --enable-gcov Reproduce code: --- ?php $fp = fopen(test.txt, w); var_dump( fwrite($fp, Text) ); // rewind the file pointer to begining var_dump( rewind($fp) ); var_dump( ftell($fp) ); var_dump( feof($fp) ); // try to read var_dump( fgetc($fp) ); var_dump( ftell($fp) ); var_dump( feof($fp) ); fclose($fp); unlink(test.txt); ? Expected result: output - php5: -- int(4) bool(true) int(0) bool(false) bool(false) int(0) bool(false) output - php6: -- int(4) bool(true) int(0) bool(false) bool(false) int(0) bool(false) Actual result: -- output - php5: -- int(4) bool(true) int(0) bool(false) bool(false) int(0) bool(true) output - php6: -- int(4) bool(true) int(0) bool(false) string(1) int(0) bool(true) output on php6 when run using run-test.php : int(4) bool(true) int(0) bool(false) string(1) ÿ int(0) bool(true) -- Edit this bug report at http://bugs.php.net/?id=42036edit=1
#41135 [Asn]: PDO SQLite BLOB field data truncated after 21 bytes
ID: 41135
Updated by: [EMAIL PROTECTED]
Reported By: rich at corephp dot co dot uk
Status: Assigned
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.1
Assigned To: wez
New Comment:
What does the following script output for you?
$db-exec('CREATE TABLE test (data blob)');
$stmt = $db-prepare(INSERT INTO test VALUES ( ? ));
$stmt-bindParam(1, $name);
$name = \x00a\x00;
var_dump($stmt-execute(), $stmt-rowCount());
$stmt = $db-prepare(select * from test);
var_dump($stmt-execute());
foreach ($stmt-fetchAll() as $row) {
echo bin2hex($row[0]), \n;
}
Previous Comments:
[2007-04-20 18:04:33] Jared dot Williams1 at ntlworld dot com
I believe it crops the data to the first \0 byte.
The ugly workaround is not to use bound parameters ...
$pic_data = 'X'.$db-quote(bin2hex($pic_data));
$stmt = $db-prepare('INSERT INTO Test (name, data) VALUES
(?,'.$pic_data.')');
$stmt-bindParam(1, $name, PDO::PARAM_STR, 60);
$stmt-execute();
[2007-04-18 17:11:47] rich at corephp dot co dot uk
The one that comes in php-5.2.1-Win32.zip (ext/php_pdo_sqlite.dll -
274,496 bytes). Please note that both the PDO SQLite AND the SQLite
(php_sqlite.dll) extensions are loaded.
[2007-04-18 16:55:34] [EMAIL PROTECTED]
Can you clarify if you're using the sqlite that comes with PHP or if
you pulled it out of a separate PECL download?
[2007-04-18 16:46:46] rich at corephp dot co dot uk
Description:
There appears to be an issue inserting binary data from a file into a
SQLite BLOB field via PDO SQLite in that the data is never fully
transferred.
The SQLite database consisted of 1 table with 3 columns:
id - integer - primary
filename - varchar(50)
data - blob
The PHP code tried to insert an image file into the BLOB field. The
code does not error in any way, nothing appears in the PHP error log, no
warnings are produced, but the data is never fully transmitted to the
SQLite database.
The ID is created properly, the filename is correct, but the data field
contains only the first 21 bytes worth of the image and nothing more.
Various different image files have been tested. The SQLite database
itself is valid, and works perfectly with BLOB fields when inserted from
the command-line. The web server is Apache 2.2.4 The SQLite database,
from phpinfo:
PDO Driver for SQLite 3.x enabled
PECL Module version 1.0.1 $Id: pdo_sqlite.c,v 1.10.2.6.2.1 2007/01/01
09:36:05 sebastian Exp $
SQLite Library 3.3.7undefined
Reproduce code:
---
$filename = 'D:/sandbox.dev/public_html/test.gif';
try
{
$db = new PDO('sqlite:D:/sandbox.dev/public_html/test.db');
}
catch (PDOException $error)
{
echo Error! : . $error-getMessage();
}
$name = 'test.gif';
$stmt = $db-prepare('INSERT INTO DataTest (filename, data) VALUES
(?,?)');
$stmt-execute(array($name, file_get_contents($filename)));
Expected result:
The SQLite database 'test.db' should be updated to contain the full
contents of test.gif in the BLOB field.
Actual result:
--
The image data is truncated after the first 21 bytes. When viewed in
Hexadecimal mode you can see that the GIF89a header was passed across,
along with the first 5 bytes of actual picture data, but after that it
is cut off. Insert a PNG file instead of a GIF and you get the PNG data
header, plus a few bytes worth of image, and again it cuts off. No
matter what type of file you insert into the BLOB, only the first 21
bytes make it.
--
Edit this bug report at http://bugs.php.net/?id=41135edit=1
#41135 [Opn]: PDO SQLite BLOB field data truncated after 21 bytes
ID: 41135
Updated by: [EMAIL PROTECTED]
Reported By: rich at corephp dot co dot uk
Status: Open
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.2.1
New Comment:
Can you clarify if you're using the sqlite that comes with PHP or if
you pulled it out of a separate PECL download?
Previous Comments:
[2007-04-18 16:46:46] rich at corephp dot co dot uk
Description:
There appears to be an issue inserting binary data from a file into a
SQLite BLOB field via PDO SQLite in that the data is never fully
transferred.
The SQLite database consisted of 1 table with 3 columns:
id - integer - primary
filename - varchar(50)
data - blob
The PHP code tried to insert an image file into the BLOB field. The
code does not error in any way, nothing appears in the PHP error log, no
warnings are produced, but the data is never fully transmitted to the
SQLite database.
The ID is created properly, the filename is correct, but the data field
contains only the first 21 bytes worth of the image and nothing more.
Various different image files have been tested. The SQLite database
itself is valid, and works perfectly with BLOB fields when inserted from
the command-line. The web server is Apache 2.2.4 The SQLite database,
from phpinfo:
PDO Driver for SQLite 3.x enabled
PECL Module version 1.0.1 $Id: pdo_sqlite.c,v 1.10.2.6.2.1 2007/01/01
09:36:05 sebastian Exp $
SQLite Library 3.3.7undefined
Reproduce code:
---
$filename = 'D:/sandbox.dev/public_html/test.gif';
try
{
$db = new PDO('sqlite:D:/sandbox.dev/public_html/test.db');
}
catch (PDOException $error)
{
echo Error! : . $error-getMessage();
}
$name = 'test.gif';
$stmt = $db-prepare('INSERT INTO DataTest (filename, data) VALUES
(?,?)');
$stmt-execute(array($name, file_get_contents($filename)));
Expected result:
The SQLite database 'test.db' should be updated to contain the full
contents of test.gif in the BLOB field.
Actual result:
--
The image data is truncated after the first 21 bytes. When viewed in
Hexadecimal mode you can see that the GIF89a header was passed across,
along with the first 5 bytes of actual picture data, but after that it
is cut off. Insert a PNG file instead of a GIF and you get the PNG data
header, plus a few bytes worth of image, and again it cuts off. No
matter what type of file you insert into the BLOB, only the first 21
bytes make it.
--
Edit this bug report at http://bugs.php.net/?id=41135edit=1
#40543 [Bgs-Opn]: pack/unpack bug
ID: 40543
Updated by: [EMAIL PROTECTED]
Reported By: dedmajor at gmail dot com
-Status: Bogus
+Status: Open
Bug Type: Unknown/Other Function
Operating System: linux x86_64
PHP Version: 5.2.1
New Comment:
This isn't bogus, this is a real bug that causes pain.
N is there for people writing code that talks to network services that
need to convert numbers from network byte order to the native format.
Also note that we get a bonus crash bug on 64-bit platforms too:
$fail = '\x00\x00\x00\x8c';
$result = unpack('Nsize', $fail);
$size = $result['size'] 0x; // BANG!
Previous Comments:
[2007-02-24 15:12:29] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You should be using either L or V, not N.
[2007-02-19 13:34:38] dedmajor at gmail dot com
Description:
#38770 not fixed(?) in 5.2.1-dev
on x86_64 AMD Opteron(tm) Processor 265 unpack don't work, on i686
Intel(R) Celeron(R) CPU 2.50GHz works fine for example.
Reproduce code:
---
php -r 'print_r(unpack(N, pack(N, 41445)));
Expected result:
Array
(
[1] = 41445
)
Actual result:
--
Array
(
[1] = -2147442203
)
--
Edit this bug report at http://bugs.php.net/?id=40543edit=1
#40289 [Asn-Fbk]: pdo_odbc Extention throws HY090 with doing binary sqlbindcol
ID: 40289
Updated by: [EMAIL PROTECTED]
Reported By: podunk dot vn at gmail dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: windows xp sp2/IIS/ASAPI
PHP Version: 5.2.0
Assigned To: wez
New Comment:
Are you using the SQL Native Client driver, or the old SQL Server
driver?
Previous Comments:
[2007-01-30 18:39:48] podunk dot vn at gmail dot com
?php
$sql =
USE [websvr]
GO
/** Object: Table [dbo].[cms_files]Script Date: 01/30/2007
13:25:58 **/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
SET ANSI_PADDING ON
GO
CREATE TABLE [dbo].[cms_files](
[fid] [int] IDENTITY(1,1) NOT NULL,
[data] [varbinary](max) NULL,
[content_type] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS
NULL,
[name] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[label] [nvarchar](255) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[pagid] [int] NOT NULL,
CONSTRAINT [PK_files] PRIMARY KEY CLUSTERED
(
[fid] ASC
)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]
GO
SET ANSI_PADDING OFF
;
$db = new
PDO('odbc:DSN=**;HOSTNAME=*;PORT=;DBNAME=**;PROTOCOL=TCPIP;UID=;PWD=;');
$db-query($sql);
$db-query(SET IDENTITY_INSERT cms_files ON);
$stmt = $db-prepare(insert into cms_files
(data,content_type,name,label,pagid,fid) values (?, ?, ?, ?, ?, ?));
$fp = fopen($_FILES['file']['tmp_name'], 'rb');
$stmt-bindParam(1, $fp, PDO::PARAM_LOB);
$stmt-bindParam(2, $_FILES['file']['type']);
$stmt-bindParam(3, $_FILES['file']['name']);
$stmt-bindParam(4, 'test');
$stmt-bindParam(5, 1);
$stmt-bindParam(6, 1);
$stmt-execute();
$stmt = $db-prepare(select content_type,data from cms_files where
fid=1);
$stmt-execute();
$stmt-bindColumn(1, $type, PDO::PARAM_STR, 256);
$stmt-bindColumn(2, $lob, PDO::PARAM_LOB);
$stmt-fetch(PDO::FETCH_BOUND);
header(Content-Type: $type);
fpassthru($lob);
print($lob);
?
[2007-01-30 18:03:17] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2007-01-30 18:01:28] podunk dot vn at gmail dot com
The latest win32 snapshot DOES NOT fix this bug.
[2007-01-30 17:16:51] podunk dot vn at gmail dot com
I got around this by changing the field type from VARBINARY(MAX) to
VARCHAR(MAX) in MSSQL 2005. It would still be nice to use the new
VARBINARY(MAX) field type.
I'm downloading the latest win32 snapshot now to see if this bug is
fixed in it.
[2007-01-30 16:14:00] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40289
--
Edit this bug report at http://bugs.php.net/?id=40289edit=1
#40848 [Opn-Csd]: compiler optimization bug randomizes array sorting
ID: 40848
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Closed
Bug Type: Arrays related
Operating System: Solaris
PHP Version: 5.2.1
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Previous Comments:
[2007-03-18 20:12:02] [EMAIL PROTECTED]
Description:
Because the wrong type is used for the return value from the qsort
callback function, the compiler screws up the actual return value,
causing the sort to be incorrect.
The following diff avoids the bug by explicitly return the right
values:
cvs diff: Diffing .
Index: array.c
===
RCS file: /repository/php-src/ext/standard/array.c,v
retrieving revision 1.308.2.21.2.25
diff -u -p -r1.308.2.21.2.25 array.c
--- array.c 16 Mar 2007 19:38:58 - 1.308.2.21.2.25
+++ array.c 18 Mar 2007 20:03:36 -
@@ -596,7 +596,7 @@ static int array_user_compare(const void
convert_to_long_ex(retval_ptr);
retval = Z_LVAL_P(retval_ptr);
zval_ptr_dtor(retval_ptr);
- return retval;
+ return retval 0 ? -1 : retval 0 ? 1 : 0;
} else {
return 0;
}
--
Edit this bug report at http://bugs.php.net/?id=40848edit=1
#39975 [Asn]: Some error in C/C++ syntax
ID: 39975
Updated by: [EMAIL PROTECTED]
Reported By: kprzemek at coig dot katowice dot pl
Status: Assigned
Bug Type: Compile Failure
Operating System: IBM AIX 5.3
PHP Version: 5.2.0
Assigned To: tony2001
New Comment:
Andy pointed me to this... I'm surprised that we have stream_shutdown_t
used as a bitfield. If I wrote that line, it was likely a late night.
We should change this:
stream_shutdown_t how:3;
to this:
unsigned int how:3;
(technically, we should also remove the int keyword from those
bitfields too, but most compilers will do the right thing).
Previous Comments:
[2007-02-02 10:55:51] wharmby at uk dot ibm dot com
The IBM XL C service team have reviewed the PMR I raised and
whilst they agree it does highlight a gcc incompatibility
the XL C compiler is adhering to the ISO standard as it
stands. They have considered fixing this in currently
supported version to improve the compatibility with gcc but
cannot due to binary compatibility issues. I am in the
process of getting the issue logged so they can consider
fixing it in a future version to improve gcc compatibility.
However, any fixed new version is in the future and the day
when all AIX users have this fixed version even further
into the future so we either fix the PHP code to avoid the
error messages or live with the error messages. The code generated by
the compiler appears OK but the documentation does say
Compilation continues and object code is generated. Error
conditions exist that the compiler can correct, but the
program might not run correctly.
which will leave the user with a slight uneasy feeling that
the code may not work.
The fixes required to avoid the messages are trivial so we should
consider modifying the code unless anyone objects.
[2007-01-17 09:45:44] wharmby at uk dot ibm dot com
PMR now raised to get XL C compiler fixed to avoid
1506-159 error messages when bitfields defined on unsigned char type's.
PMR number is 40951,999,866
[2007-01-11 12:33:18] wharmby at uk dot ibm dot com
Having acquired V5 documentation I can now confirm that
-qlanglvl=extc89|extc99 is not supported under XL C V5 so cant use that
to avoid the errors reported above.
I am in the process of raising a PMR against the XL C compiler to get
the compiler fixed to avoid the error
message when bit fields defined on unsigned char types, e.g
1506-159 (E) Bit-field type specified for how is not valid. Type
unsigned assumed.
Will post again when I have news on progress of PMR
[2007-01-05 18:36:05] wharmby at uk dot ibm dot com
I have conducted a series of experiments today and results
so far are listed below:
My environment:
OS: AIX 5.2.0.0
Compiler : IBM(R) XL C Enterprise Edition V7.0
PHP: PHP 5.2.1RC2-dev
With the following PHP configuration
./configure -enable-debug --enable-maintainer-zts --disable-cgi
--enable-cli --with-libxml-dir=/u2/wharmby/freeware/xml2
--prefix=/u2/wharmby/php5
Ignoring the normal W(arning) messages the only compiler
messages I get are E(rror) messages about badly defined
bit-field's. I get multiple instances of the following:
/u2/wharmby/php5.2-200701040730/main/streams/php_stream_transport.h,
line 136.27: 1506-159 (E) Bit-field type specified for how is not
valid. Type unsigned assumed.
The offending code is as follows:
typedef struct _php_stream_xport_param {
enum {
STREAM_XPORT_OP_BIND, STREAM_XPORT_OP_CONNECT,
STREAM_XPORT_OP_LISTEN, STREAM_XPORT_OP_ACCEPT,
STREAM_XPORT_OP_CONNECT_ASYNC,
STREAM_XPORT_OP_GET_NAME,
STREAM_XPORT_OP_GET_PEER_NAME,
STREAM_XPORT_OP_RECV,
STREAM_XPORT_OP_SEND,
STREAM_XPORT_OP_SHUTDOWN
} op;
unsigned int want_addr:1;
unsigned int want_textaddr:1;
unsigned int want_errortext:1;
stream_shutdown_t how:3; THIS IS LINE FLAGGED
e.t.c
stream_shutdown_t is defined as follows:
typedef enum {
STREAM_SHUT_RD,
STREAM_SHUT_WR,
STREAM_SHUT_RDWR
} stream_shutdown_t;
This is a variation of the bitfield problem reported above
when compiling hash_tiger.c. The complete list of messages for this
with xlc V7 are:
cc -Iext/hash/ -I/u2/wharmby/php5.2-200701040730/ext/hash/
-DPHP_ATOM_INC
-I/u2/wharmby/php5.2-200701040730/include
-I/u2/wharmby/php5.2-200701040730/main
-I/u2/wharmby/php5.2-200701040730
-I/u2/wharmby/freeware/xml2/include/libxml2
-I/u2/wharmby/php5.2-200701040730/ext/date/lib
-I/u2/wharmby/php5.2-200701040730/TSRM
-I/u2/wharmby/php5.2-200701040730/Zend -D_THREAD_SAFE -I/usr/include
-g
-DZTS -c /u2/wharmby/php5.2-200701040730/ext/hash/hash_tiger.c -o
ext/hash/hash_tiger.o
#39930 [Opn-Bgs]: Error passing Word macro arguments
ID: 39930
Updated by: [EMAIL PROTECTED]
Reported By: poon dot fung at gmail dot com
-Status: Open
+Status: Bogus
Bug Type: COM related
Operating System: Windows XP
PHP Version: 5.2.0
New Comment:
Andy reports that this is not a bug in PHP.
Previous Comments:
[2007-01-22 14:53:56] wharmby at uk dot ibm dot com
I have recreated the problem reported by this bug report
using the instructions provided and get exactly the error
reported. However, after investigating of the problem I am now of the
opinion that the defect lies in Word and not in
PHP or the COM extension.
First of all the problem appears to have nothing to do with
whether the macro is in the default macro file or not. The
error has more to do with how the macroname parameter itself is
specified.
For a macro defined in the default macro file which has no
arguments then any of the following work without problems:
$word-Application-Run(phptest1);
$word-Application-Run(NewMacros.phptest1);
$word-Application-Run(Normal.NewMacros.phptest1);
However, for a macro with one argument then either of the
following are OK:
$word-Application-Run(phptest2,string1);
$word-Application-Run(NewMacros.phptest2, string1);
but when the full name for the macro is specified as follows
$word-Application-Run(Normal.NewMacros.phptest2,
string1);
then the reported exception is thrown:
btw the scode in the returned EXCEPINFO structure is 0x80020003 ,
i.e specified macro not found,
but bstrSource and bstrDescription are both NULL hence the rather
unhelpful exception message produced by COM extension, i.e
Fatal error: Uncaught exception 'com_exception' with message 'Source:
Unknown Description: Unknown' in
C:\Eclipse-PHP\workspace\Testcases\COM\d39930.php:30
If I define the same macros in another macro file, e.g AndyMacros,
then I get the same results,
So it looks like an issue when the template name is specified in the
macroname parametr when the macro takes
1 or more arguments, i.e a macro name of the form
template.module.macro is specified WITH arguments.
To further show this is not a PHP or COM issue I rewrote the testcase
using VB as follows:
http://www.pastebin.ca/324546
When I run this script with either of lines 18 or 19 not commented out,
i.e
word.Application.Run Normal.NewMacros.phptest2,
string1
or
word.Application.Run Normal.NewMacros.phptest3,
string1, string2
then the script fails with
C:\VBscripts\d39930.vbs(18, 1) Microsoft VBScript runtime error:
Object doesn't support this property or method.
As with PHP errors are only reported when the template is specified
in the macroname. This suggests to me that the reported problem does
indeed lie in Word and not PHP.
Searching the web I did find this very old bug report for Word 97 from
2000 which looks like a similar issue:
http://support.microsoft.com/kb/190235.
This suggests the template name be removed from the macroname
argument as a workaround which ties in with
my findings above.
[2007-01-19 09:23:00] wharmby at uk dot ibm dot com
As promised on internals list back in December I will attempt to
resolve some of the outstanding COM defects.
I will start with this one.
[2007-01-04 07:43:19] poon dot fung at gmail dot com
Here is the output of my test run on
http://snaps.php.net/win32/php5.2-win32-latest.zip.
--- START OUTPUT ---
D:\php-bug2bug2-test1.php
TEST #1 OK!
D:\php-bug2bug2-test2.php
TEST #2 OK!
D:\php-bug2bug2-test3.php
TEST #3 OK!
D:\php-bug2bug2-test4.php
TEST #4 OK!
D:\php-bug2bug2-test5.php
PHP Fatal error: Uncaught exception 'com_exception' with message
'Source: Unknown
Description: Unknown' in D:\php-bug2\bug2-test5.php:9
Stack trace:
#0 D:\php-bug2\bug2-test5.php(9): variant-Run('Normal.MyModule...',
'Some value')
#1 {main}
thrown in D:\php-bug2\bug2-test5.php on line 9
D:\php-bug2bug2-test6.php
PHP Fatal error: Uncaught exception 'com_exception' with message
'Source: Unknown
Description: Unknown' in D:\php-bug2\bug2-test6.php:9
Stack trace:
#0 D:\php-bug2\bug2-test6.php(9): variant-Run('Normal.MyModule...',
'Some value', 'Some value')
#1 {main}
thrown in D:\php-bug2\bug2-test6.php on line 9
D:\php-bug2
--- END OUTPUT ---
Here are the test programs.
--- TEST 1 ---
?php
// First test -- This works fine
$word = new COM('Word.Application') or die('Start Word automation
failed.');
$word-Documents-Open('D:\php-bug2\testme.doc');
$word-Application-Run('phptest1');
$word-Quit();
$word = null;
print TEST #1 OK!\n;
?
--- TEST 2 ---
?php
// Second test -- This works fine
$word = new COM('Word.Application') or die('Start Word automation
#39822 [Asn-Sus]: new PDO() doesn't work with firebird
ID: 39822
Updated by: [EMAIL PROTECTED]
Reported By: bx at clansphere dot de
-Status: Assigned
+Status: Suspended
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2006-12-13 (snap)
Assigned To: wez
New Comment:
Looking for a maintainer
Previous Comments:
[2006-12-13 22:08:25] bx at clansphere dot de
Description:
using try/catch doesn't work for firebird like it works with other
rdbms extensions. i think the problem is that firebird returns
something (NULL) so that try expects all went well, but it is not
checking for the PDO object itself.
i am using is_object() currently to look for errors, but that way i
can't get errorcodes like 'database does not exist' for example and
even when track_errors is enabled $php_errormsg is empty.
Reproduce code:
---
try {
$connection = new PDO('firebird:dbname=test.fdb', $user,
$password);
}
catch(PDOException $error) {
echo $error-getMessage();
}
Expected result:
catch can be called to get the exact error
Actual result:
--
try statement thinks everything is ok
--
Edit this bug report at http://bugs.php.net/?id=39822edit=1
#39215 [Asn-WFx]: Inappropriate close of stdin/stdout/stderr
ID: 39215 Updated by: [EMAIL PROTECTED] Reported By: tstarling at wikimedia dot org -Status: Assigned +Status: Wont fix Bug Type: Streams related Operating System: Linux Windows PHP Version: 5CVS-2006-10-20 (CVS) Assigned To: wez New Comment: We added the constant STDIN to avoid this issue. Previous Comments: [2006-10-21 01:56:37] tstarling at wikimedia dot org Although I cringe to say it, it looks like the easiest way to avoid the access violation on windows may be to temporarily disable assertions and parameter checking. Some references: _close: http://msdn2.microsoft.com/en-us/library/5fzwd5ss.aspx _set_invalid_parameter_handler: http://msdn2.microsoft.com/en-us/library/a9yf33zb.aspx [2006-10-21 01:20:14] tstarling at wikimedia dot org In reply to Tony: they're not mutually exclusive statements, you just need to prevent implicit or duplicate closes while allowing explicit closes. This could be done by setting a flag in the stream structure at the end of php_stream_url_wrap_php(). The flag could be detected in _php_stream_free() and a close avoided. Duplicate closes can be prevented either by keeping an array of filedescriptor states in memory, or by somehow detecting the state of the FD before attempting a close. I decided to submit a bug report rather than a patch because I wasn't sure about the best way to implement it. According to the MSVC Run-Time Library Reference, regarding _close(): This function validates its parameters. If fd is a bad file descriptor, the invalid parameter handler is invoked, as described in Parameter Validation. If execution is allowed to continue, the functions returns -1 and errno is set to EBADF. And on parameter validation generally: The behavior of the C Runtime when an invalid parameter is found is to call the currently assigned invalid parameter handler. The default invalid parameter handler raises an Access Violation exception, which normally makes continued execution impossible. In Debug mode, an assertion is also raised. I have compiled PHP in debug mode, so here is the assertion as documented: Debug assertion failed! Program: ... File: close.c Line: 48 Expression: (_osfile(fh) FOPEN) Then the access violation: msvcr80d.dll!00c49dc0() [Frames below may be incorrect and/or missing, no symbols loaded for msvcr80d.dll] msvcr80d.dll!00c3f564() msvcr80d.dll!00c7ff39() php5ts_debug.dll!php_stdiop_close(_php_stream * stream=0x014f19c0, int close_handle=1, void * * * tsrm_ls=0x003c4f90) Line 380 + 0xf bytes C php5ts_debug.dll!_php_stream_free(_php_stream * stream=0x014f19c0, int close_options=11, void * * * tsrm_ls=0x003c4f90) Line 342 + 0x1e bytes C php5ts_debug.dll!stream_resource_regular_dtor(_zend_rsrc_list_entry * rsrc=0x014f8a50, void * * * tsrm_ls=0x003c4f90) Line 1365 + 0xf bytes C php5ts_debug.dll!list_entry_destructor(void * ptr=0x014f8a50) Line 184 + 0x12 bytesC php5ts_debug.dll!zend_hash_del_key_or_index(_hashtable * ht=0x003c76d8, char * arKey=0x, unsigned int nKeyLength=0, unsigned long h=1, int flag=1) Line 492 + 0x11 bytes C php5ts_debug.dll!_zend_list_delete(int id=1, void * * * tsrm_ls=0x003c4f90) Line 58 + 0x24 bytes C php5ts_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x01529758, char * __zend_filename=0x10714738, unsigned int __zend_lineno=35) Line 60 + 0xf bytes C php5ts_debug.dll!_zval_dtor(_zval_struct * zvalue=0x01529758, char * __zend_filename=0x107177b8, unsigned int __zend_lineno=33) Line 35 + 0x17 bytes C php5ts_debug.dll!free_zend_constant(_zend_constant * c=0x01529758) Line 33 + 0x17 bytesC php5ts_debug.dll!zend_hash_apply_deleter(_hashtable * ht=0x003c6f08, bucket * p=0x01529700) Line 606 + 0x11 bytes C php5ts_debug.dll!zend_hash_reverse_apply(_hashtable * ht=0x003c6f08, int (void *, void * * *)* apply_func=0x1029adc0, void * * * tsrm_ls=0x003c4f90) Line 736 + 0xd bytes C php5ts_debug.dll!clean_non_persistent_constants(void * * * tsrm_ls=0x003c4f90) Line 162 + 0x23 bytes C php5ts_debug.dll!shutdown_executor(void * * * tsrm_ls=0x003c4f90) Line 303 + 0x9 bytesC php5ts_debug.dll!zend_deactivate(void * * * tsrm_ls=0x003c4f90) Line 840 + 0x9 bytes C php5ts_debug.dll!php_request_shutdown(void * dummy=0x) Line 1300 + 0x9 bytesC [2006-10-20 16:38:32] [EMAIL PROTECTED] .. and the double close is actually much easier to reproduce with just: ?php $s = fopen(php://stdin, r); ? On shutdown both $s and STDIN constant are destroyed, but they both point to the same resource
#39215 [WFx-Asn]: Inappropriate close of stdin/stdout/stderr
ID: 39215 Updated by: [EMAIL PROTECTED] Reported By: tstarling at wikimedia dot org -Status: Wont fix +Status: Assigned Bug Type: Streams related Operating System: Linux Windows PHP Version: 5CVS-2006-10-20 (CVS) Assigned To: wez New Comment: Hmm, someone changed the close behavior of those constants. Re-opening while I check into it. Previous Comments: [2006-10-21 21:00:54] [EMAIL PROTECTED] We added the constant STDIN to avoid this issue. [2006-10-21 01:56:37] tstarling at wikimedia dot org Although I cringe to say it, it looks like the easiest way to avoid the access violation on windows may be to temporarily disable assertions and parameter checking. Some references: _close: http://msdn2.microsoft.com/en-us/library/5fzwd5ss.aspx _set_invalid_parameter_handler: http://msdn2.microsoft.com/en-us/library/a9yf33zb.aspx [2006-10-21 01:20:14] tstarling at wikimedia dot org In reply to Tony: they're not mutually exclusive statements, you just need to prevent implicit or duplicate closes while allowing explicit closes. This could be done by setting a flag in the stream structure at the end of php_stream_url_wrap_php(). The flag could be detected in _php_stream_free() and a close avoided. Duplicate closes can be prevented either by keeping an array of filedescriptor states in memory, or by somehow detecting the state of the FD before attempting a close. I decided to submit a bug report rather than a patch because I wasn't sure about the best way to implement it. According to the MSVC Run-Time Library Reference, regarding _close(): This function validates its parameters. If fd is a bad file descriptor, the invalid parameter handler is invoked, as described in Parameter Validation. If execution is allowed to continue, the functions returns -1 and errno is set to EBADF. And on parameter validation generally: The behavior of the C Runtime when an invalid parameter is found is to call the currently assigned invalid parameter handler. The default invalid parameter handler raises an Access Violation exception, which normally makes continued execution impossible. In Debug mode, an assertion is also raised. I have compiled PHP in debug mode, so here is the assertion as documented: Debug assertion failed! Program: ... File: close.c Line: 48 Expression: (_osfile(fh) FOPEN) Then the access violation: msvcr80d.dll!00c49dc0() [Frames below may be incorrect and/or missing, no symbols loaded for msvcr80d.dll] msvcr80d.dll!00c3f564() msvcr80d.dll!00c7ff39() php5ts_debug.dll!php_stdiop_close(_php_stream * stream=0x014f19c0, int close_handle=1, void * * * tsrm_ls=0x003c4f90) Line 380 + 0xf bytes C php5ts_debug.dll!_php_stream_free(_php_stream * stream=0x014f19c0, int close_options=11, void * * * tsrm_ls=0x003c4f90) Line 342 + 0x1e bytes C php5ts_debug.dll!stream_resource_regular_dtor(_zend_rsrc_list_entry * rsrc=0x014f8a50, void * * * tsrm_ls=0x003c4f90) Line 1365 + 0xf bytes C php5ts_debug.dll!list_entry_destructor(void * ptr=0x014f8a50) Line 184 + 0x12 bytesC php5ts_debug.dll!zend_hash_del_key_or_index(_hashtable * ht=0x003c76d8, char * arKey=0x, unsigned int nKeyLength=0, unsigned long h=1, int flag=1) Line 492 + 0x11 bytes C php5ts_debug.dll!_zend_list_delete(int id=1, void * * * tsrm_ls=0x003c4f90) Line 58 + 0x24 bytes C php5ts_debug.dll!_zval_dtor_func(_zval_struct * zvalue=0x01529758, char * __zend_filename=0x10714738, unsigned int __zend_lineno=35) Line 60 + 0xf bytes C php5ts_debug.dll!_zval_dtor(_zval_struct * zvalue=0x01529758, char * __zend_filename=0x107177b8, unsigned int __zend_lineno=33) Line 35 + 0x17 bytes C php5ts_debug.dll!free_zend_constant(_zend_constant * c=0x01529758) Line 33 + 0x17 bytesC php5ts_debug.dll!zend_hash_apply_deleter(_hashtable * ht=0x003c6f08, bucket * p=0x01529700) Line 606 + 0x11 bytes C php5ts_debug.dll!zend_hash_reverse_apply(_hashtable * ht=0x003c6f08, int (void *, void * * *)* apply_func=0x1029adc0, void * * * tsrm_ls=0x003c4f90) Line 736 + 0xd bytes C php5ts_debug.dll!clean_non_persistent_constants(void * * * tsrm_ls=0x003c4f90) Line 162 + 0x23 bytes C php5ts_debug.dll!shutdown_executor(void * * * tsrm_ls=0x003c4f90) Line 303 + 0x9 bytesC php5ts_debug.dll!zend_deactivate(void * * * tsrm_ls=0x003c4f90) Line 840 + 0x9 bytes C php5ts_debug.dll!php_request_shutdown(void * dummy=0x) Line 1300 + 0x9 bytesC [2006-10-20 16:38:32] [EMAIL
#38488 [Csd]: Access to php://stdin and faily crashes PHP on win32
ID: 38488 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Closed Bug Type: Streams related Operating System: win32 PHP Version: 5CVS-2006-08-18 (CVS) New Comment: What you were seeing under the debugger was an internal exception which is expected if the handle is not a pipe. GetFileType returns FILE_TYPE_PIPE for pipes and sockets, so now it's not as precise in its classification as it once was. Previous Comments: [2006-08-22 06:20:15] [EMAIL PROTECTED] Fixed in CVS HEAD, PHP_5_2 and PHP_5_1. The problem was not in _get_osfhandle(), but in GetNamedPipeInfo() that expects PIPE's HANDLE. [2006-08-22 03:29:57] [EMAIL PROTECTED] PHP crashes only with MS Debugging Tools for Windows, however bug don't go away without them. The problem that _get_osfhandle(0) returns some invalid HANDLE (for me it is 3), and then GetNamedPipeIndo() may crash. I'll probably look into problem by myself. [2006-08-18 04:11:52] [EMAIL PROTECTED] I'm unable to get my system to crash (CGI and CLI). What SAPI are you using? [2006-08-18 02:31:47] [EMAIL PROTECTED] Description: Access to standard streams using php://stdin and family names produces crash. The reason probably is in a buggy _get_osfhandle() function that doesn't return proper HANDLES for standard system streams. We need find out a workaround for this problem. the bug is probably related to bug #7960 Reproduce code: --- ?php $f = fopen(php://stdout, w+); fwrite($f, Hello\n); ? Expected result: Hello Actual result: -- Crash with the following stack trace NTDLL! 7c90eb74() NTDLL! 7c90eb94() _php_stream_fopen_from_fd(int 0, const char * 0x00416fb0 `string', const char * 0x, int 0, char * 0x1070a25c `string', unsigned int 246, char * 0x, unsigned int 0, void * * * 0x02714fe0) line 200 + 24 bytes php_stream_url_wrap_php(_php_stream_wrapper * 0x108a5d28 _php_stream_php_wrapper, char * 0x00416fa6, char * 0x00416fb0 `string', int 8, char * * 0x, _php_stream_context * 0x, int 1, char * 0x106dd51c `string', unsigned int 1774, char * 0x004165c8 `string', unsigned int 498, void * * * 0x02714fe0) line 246 + 41 bytes _php_stream_open_wrapper_ex(char * 0x00416fa0 `string', char * 0x00416fb0 `string', int 0, char * * 0x, _php_stream_context * 0x, int 0, char * 0x004165c8 `string', unsigned int 498, char * 0x, unsigned int 0, void * * * 0x02714fe0) line 1774 + 111 bytes cli_register_file_handles(void * * * 0x02714fe0) line 498 + 52 bytes main(int 2, char * * 0x026f8fc0) line 1030 + 12 bytes -- Edit this bug report at http://bugs.php.net/?id=38488edit=1
#39215 [Asn]: Inappropriate close of stdin/stdout/stderr
ID: 39215
Updated by: [EMAIL PROTECTED]
Reported By: tstarling at wikimedia dot org
Status: Assigned
Bug Type: Streams related
Operating System: Linux Windows
PHP Version: 5CVS-2006-10-20 (CVS)
-Assigned To: wez
+Assigned To: iliaa
New Comment:
This patch is scheduled for PHP 5.2.1.
Suggested workaround is to use the STDIN constant instead of explicitly
opening php://stdin.
Index: ext/standard/php_fopen_wrapper.c
===
RCS file: /repository/php-src/ext/standard/php_fopen_wrapper.c,v
retrieving revision 1.45.2.4.2.2
diff -u -p -r1.45.2.4.2.2 php_fopen_wrapper.c
--- ext/standard/php_fopen_wrapper.c5 Jul 2006 17:38:14 -
1.45.2.4.2.2
+++ ext/standard/php_fopen_wrapper.c21 Oct 2006 22:13:22 -
@@ -191,11 +191,41 @@ php_stream * php_stream_url_wrap_php(php
}
if (!strcasecmp(path, stdin)) {
- fd = !strcmp(sapi_module.name, cli) ? STDIN_FILENO :
dup(STDIN_FILENO);
+ if (!strcmp(sapi_module.name, cli)) {
+ static int cli_in = 0;
+ fd = STDIN_FILENO;
+ if (cli_in) {
+ fd = dup(fd);
+ } else {
+ cli_in = 1;
+ }
+ } else {
+ fd = dup(STDIN_FILENO);
+ }
} else if (!strcasecmp(path, stdout)) {
- fd = !strcmp(sapi_module.name, cli) ? STDOUT_FILENO :
dup(STDOUT_FILENO);
+ if (!strcmp(sapi_module.name, cli)) {
+ static int cli_out = 0;
+ fd = STDOUT_FILENO;
+ if (cli_out++) {
+ fd = dup(fd);
+ } else {
+ cli_out = 1;
+ }
+ } else {
+ fd = dup(STDOUT_FILENO);
+ }
} else if (!strcasecmp(path, stderr)) {
- fd = !strcmp(sapi_module.name, cli) ? STDERR_FILENO :
dup(STDERR_FILENO);
+ if (!strcmp(sapi_module.name, cli)) {
+ static int cli_err = 0;
+ fd = STDERR_FILENO;
+ if (cli_err++) {
+ fd = dup(fd);
+ } else {
+ cli_err = 1;
+ }
+ } else {
+ fd = dup(STDERR_FILENO);
+ }
} else if (!strncasecmp(path, filter/, 7)) {
/* Save time/memory when chain isn't specified */
if (strchr(mode, 'r') || strchr(mode, '+')) {
Previous Comments:
[2006-10-21 21:10:21] [EMAIL PROTECTED]
Hmm, someone changed the close behavior of those constants. Re-opening
while I check into it.
[2006-10-21 21:00:54] [EMAIL PROTECTED]
We added the constant STDIN to avoid this issue.
[2006-10-21 01:56:37] tstarling at wikimedia dot org
Although I cringe to say it, it looks like the easiest way to avoid the
access violation on windows may be to temporarily disable assertions and
parameter checking. Some references:
_close: http://msdn2.microsoft.com/en-us/library/5fzwd5ss.aspx
_set_invalid_parameter_handler:
http://msdn2.microsoft.com/en-us/library/a9yf33zb.aspx
[2006-10-21 01:20:14] tstarling at wikimedia dot org
In reply to Tony: they're not mutually exclusive statements, you just
need to prevent implicit or duplicate closes while allowing explicit
closes. This could be done by setting a flag in the stream structure at
the end of php_stream_url_wrap_php(). The flag could be detected in
_php_stream_free() and a close avoided. Duplicate closes can be
prevented either by keeping an array of filedescriptor states in
memory, or by somehow detecting the state of the FD before attempting a
close.
I decided to submit a bug report rather than a patch because I wasn't
sure about the best way to implement it.
According to the MSVC Run-Time Library Reference, regarding _close():
This function validates its parameters. If fd is a bad file
descriptor, the invalid parameter handler is invoked, as described in
Parameter Validation. If execution is allowed to continue, the
functions returns -1 and errno is set to EBADF.
And on parameter validation generally:
The behavior of the C Runtime when an invalid parameter is found is to
call the currently assigned invalid parameter handler. The default
invalid parameter handler raises an Access Violation exception, which
normally makes continued execution impossible
#39224 [Asn]: There is no way to use Unix98 pty on proc_open()
ID: 39224
Updated by: [EMAIL PROTECTED]
Reported By: joe at asial dot co dot jp
Status: Assigned
Bug Type: Unknown/Other Function
Operating System: ALL
PHP Version: 5.1.6
Assigned To: wez
New Comment:
It was disabled because Sascha didn't think the configure check was
good enough.
Previous Comments:
[2006-10-21 21:34:42] [EMAIL PROTECTED]
It has been disabled by Wez intentionally (unfortunately I don't know
the exact reason why).
Assigned to him, maybe he can add some comments.
[2006-10-21 21:20:02] joe at asial dot co dot jp
Description:
I cannot compile with support for Unix98 pty.
Following is source code from ext/standard/proc_open.c line 64 to 68.
#if 0 HAVE_PTSNAME HAVE_GRANTPT HAVE_UNLOCKPT
HAVE_SYS_IOCTL_H HAVE_TERMIOS_H
# include sys/ioctl.h
# include termios.h
# define PHP_CAN_DO_PTS 1
#endif
I think that '#if 0 HAVE_PTSNAME ...' is wrong, '#if HAVE_PTSNAME
...' is right.
Reproduce code:
---
$descriptorspec = array(
0 = array(pty),
1 = array(pty),
2 = array(pty)
);
$cwd = '/tmp';
$env = array('some_option' = 'aeiou');
$process = proc_open('php', $descriptorspec, $pipes, $cwd, $env);
Expected result:
No error.
Actual result:
--
PHP Warning: proc_open(): pty pseudo terminal not supported on this
system in .php on line xx
--
Edit this bug report at http://bugs.php.net/?id=39224edit=1
#39161 [Asn]: parameter names not sent to prepared statement
ID: 39161 Updated by: [EMAIL PROTECTED] Reported By: aspen dot olmsted at alliance dot biz Status: Assigned Bug Type: PDO related Operating System: windows xp sp 2 PHP Version: 5CVS-2006-10-15 (snap) Assigned To: wez New Comment: That's correct. This is currently the expected behavior. Previous Comments: [2006-10-15 15:35:42] aspen dot olmsted at alliance dot biz Description: If I call a SQL 2000 stored procedure through pdo odbc in a prepared statement it will not set the proper field order if the order does not match the parameter order in the SP. Reproduce code: --- 2000 SQL SP (can be empty): create procedure pdo_test2 @Param1 int, @Param2 varchar(100) as PHP Code: $a[param1] = '26050'; $a[param2] = 'test'; $sql = exec pdo_test2 @param2 = :param2,@param1 = :param1; $stmt = $dbh-prepare($sql); $x = $stmt-execute($a); Expected result: The column order should not matter if the names are passed Actual result: -- If I trace in sql I see the following: exec sp_prepare @P1 output, N'@Param1 int,@Param2 varchar(100)', N'exec pdo_test2 @param2 = @Param1,@param1 = @Param2', 1 -- Edit this bug report at http://bugs.php.net/?id=39161edit=1
#39141 [Asn-Bgs]: Only one prepared statement allowed per pdo object
ID: 39141 Updated by: [EMAIL PROTECTED] Reported By: aspen dot olmsted at alliance dot biz -Status: Assigned +Status: Bogus Bug Type: PDO related Operating System: Windows XP SP2 PHP Version: 5CVS-2006-10-12 (snap) Assigned To: wez New Comment: Expected behavior. You must consume all the rows from the first statement handle before kicking off a second query. You can do this more conveniently using fetchAll(). Previous Comments: [2006-10-12 19:53:36] aspen dot olmsted at alliance dot biz Description: If I try to open a 2nd statement handle against prepared statement on SQL 2000 and windows the 2nd attempt will fail. I can create a new object per statement and it is fine. The problem is only happening on prepared stored procedures. If I prepare a sql statement it seems fine. Reproduce code: --- $stmt = $dbh-prepare(exec pdo_test); $stmt-execute(); echo $x . . var_dump($stmt-fetch()) . br; // $stmt = null; $stmt2 = $dbh-prepare(exec pdo_test); $stmt2-execute(); echo $x . . var_dump($stmt2-fetch()) . br; Here is the sql to create SP: create procedure pdo_test as select 'Hello' msg Expected result: Hoping both statements would print the array with Hello in it Actual result: -- The second result will print false. If I uncomment the $stmt = null; then everything works great. -- Edit this bug report at http://bugs.php.net/?id=39141edit=1
#39130 [Asn]: Compile failure with the compiler of VC++ 2005
ID: 39130 Updated by: [EMAIL PROTECTED] Reported By: ben dot yan at msn dot com Status: Assigned Bug Type: Compile Failure Operating System: Windows PHP Version: 5.2.0RC5 Assigned To: wez New Comment: I've seen this before; I think have the fix on a company laptop that is currently occupied and I'll commit it just as soon as I can get access to it again. Previous Comments: [2006-10-12 08:28:29] [EMAIL PROTECTED] Wez, you added those lines for VC++ 2005 compability. Could you have a look? [2006-10-11 18:29:43] ben dot yan at msn dot com Description: Compile with VS.NET 2005 c:\program files\microsoft visual studio 8\vc\include\sys\stat.inl(44) : error C2466: cannot allocate an array of constant size 0 c:\program files\microsoft visual studio 8\vc\include\sys\stat.inl(49) : error C2466: cannot allocate an array of constant size 0 c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(39) : error C2466: cannot allocate an array of constant size 0 c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(44) : error C2466: cannot allocate an array of constant size 0 c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(49) : error C2466: cannot allocate an array of constant size 0 c:\program files\microsoft visual studio 8\vc\include\sys\utime.inl(78) : error C2466: cannot allocate an array of constant size 0 Reproduce code: --- look the zend.h : ... #include stdio.h /* * general definitions */ #ifdef ZEND_WIN32 # include zend_config.w32.h # define ZEND_PATHS_SEPARATOR ';' #elif defined(XXX) ... #endif Expected result: Look the line 151 at the ../main/config.w32.h: /* vs.net 2005 has a 64-bit time_t. This will likely break * 3rdParty libs that were built with older compilers; switch * back to 32-bit */ #define _USE_32BIT_TIME_T 1 #define HAVE_STDLIB_H 1 so the config.w32.h should be included first. But it isn't so in the zend.h: #include stdio.h /* * general definitions */ #ifdef ZEND_WIN32 # include zend_config.w32.h # define ZEND_PATHS_SEPARATOR ';' #elif defined(XXX) ... #endif This would induce the compile error. and if #include stdio.h BEHIND the #ifdef ZEND_WIN32 # include zend_config.w32.h # define ZEND_PATHS_SEPARATOR ';' #elif defined(XXX) ... #endif ,it will be ok. Actual result: -- error C2466: cannot allocate an array of constant size 0 -- Edit this bug report at http://bugs.php.net/?id=39130edit=1
#38834 [Asn-Csd]: pdo_odbc
ID: 38834
Updated by: [EMAIL PROTECTED]
Reported By: aspen dot olmsted at alliance dot biz
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.1.6
Assigned To: wez
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Grab a PHP 5.2 snapshot from snaps.php.net
Previous Comments:
[2006-10-09 23:30:31] mmatz at 2advanced dot com
Is there any workaround for this issue? I'm trying to write a script
that will migrate from an old MSSQL database (with arcane schema) to a
new and improved MySQL 5 database. Naturally, I'm going to need to get
all of the data out of these long text fields. Using mssql_* (or
PDO_DBLIB mssql functions, or ADOdb mssql functions) I get the error:
Unicode data in a Unicode-only collation or ntext data cannot be sent
to clients using DB-Library (such as ISQL) or ODBC version 3.7 or
earlier.
So that's why I'm using ODBC, which will actually retrieve data, but
I'm faced with the problem you describe.
[2006-09-15 13:01:50] aspen dot olmsted at alliance dot biz
I tried on 5.2.0RC5-dev
and I have the same result as 5.1 duplicated columns in the array and
everything after the large text field is blank
[2006-09-15 07:03:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-09-15 02:56:50] aspen dot olmsted at alliance dot biz
I noticed that the array returned is actually duplicating the columns.
One for each name and then one per number:
array(6) {
[scpFreeText]=
string(7895) UL class=ul3B$2,500$4,999/B
LI2 x 4, Inc
LIAlan Brasington Network
LIEleanor S. Applewhaite
LIMartha and Thomas G. Armstrong
LIJody and John Arnhold
LIPage Ashley
LIIn Memory of Betty L. Asiel
LIRosalind Case Avrett
LISusan Baker and Michael Lynch
LILucy and Joel Banker
LIDave Barger
LIRichard and Eslyn Bassuk
LIGinette and Joshua Becker
LIMargaret and James Bernstein
LILeslie and George C. Biddle
LIMarilyn Friedman and Thomas Block
LIHarvi and Bob Bloom
LIThe Blythmour Corporation
LIBrian R. Meara Public Relations Inc.
LIThe Brodsky Organization
LIDavid Brown and Helen Gurley Brown
LIMarian Culbertson Hvolbeck
LIMr. and Mrs. Willard C. Butcher
LIFrank and Nancy Bynum
LIMs. Deborah Carmichael
LIJohn K. Castle
LIElizabeth and Jay Chandler
LIMr. and Mrs. Michael J. Chasanoff
LICitigroup Private Bank
LIConnie and Richard W. Cohen
LIColgate-Palmolive Company
LICon Edison
LIPeter and Julie Cummings
LIMs. Marjorie M. Curry
LIMatthew J. Cvetic
LID. Ronald Daniel and Lise Scott
LILucy and Mike Danziger
LIMr. and Mrs. J. Dennis Delafield
LIJamie deRoy
LIGayle and Dan Devin
LIValerie and Charles Diker
LIRobert and Marti Dinerstein
LIDiscovery Communications, Inc.
LIDMJM Harris
LIAnthony Dolce
LIMs. Domitilia M. dos Santos
LIIn Memoriam - Mr. and Mrs. Gerald A. Dundon
LIEdison Properties, LLC
LIEdmar
LILewis and Judy Eisenberg
LINancy Donohue and Diane Elam
LIEmpire BlueCross BlueShield
LIPaula S. Epsteen
LIStanley Epstein
LIMr. and Mrs. Leroy Fadem
LIRoger N. Farah/Polo Ralph Lauren Foundation
LIFiona Morgan Fein
LIMr. and Mrs. Massimo Ferragamo
LIArlene and Robert Fischer
LIAndrew Frackman and Emily Braun
LIJuliet Frank
LIFreedom Forum
LICynthia and Eliot Fried
LIThe Barry Friedberg and Charlotte Moss Family Foundation
LIPatrice and Louis Friedman
LIIn Memory of Ella and George Geiger
LIMs. Lynn Gilbert
LIMr. amp; Mrs. Richard F. Goodman
LIMs. Beth S. Gould
LIMr. and Mrs. Harry E. Gould, Jr.
LIGray Family Foundation
LIAnnette Green
LIMr. and Mrs. Maurice R. Greenberg/The Greenberg Foundation
LINaava and Sanford Grossman
LIDoris Grzymski
LIRalph and Calla Guild
LIMr. and Mrs. John H. Gutfreund
LIGerry Harper
LIMary W. Harriman Foundation
LITed amp; Dina Merrill Hartley
LIMrs. Eva Hartman
LILinda and Mel Heineman
LIMarian S. Heiskell
LIDavid M. Helpern
LIBuck Henry Charitable Fund Administered by the BRnbsp; nbsp;
California Community Foundation
LIJohn S. Herold, Inc.
LIEllen and David S. Hirsch
LIJacqueline and Robert Hochberg
LIWill Holt
LICarol and Howard Holtzmann
LIRuth W. Houghton
LIMr. and Mrs. Charles O. Hoyt
LIJill and Ken Iscol
LIDr. and Mrs. Julius H. Jacobson II
LILinda and Morton Janklow
LIFreda S. Johnson
LIMarnee and Eric Kaltman
LIThe Kandell Fund
LIMaury I
#38054 [Asn-Fbk]: PDO with db2 returning column names but not data
ID: 38054
Updated by: [EMAIL PROTECTED]
Reported By: john dot enevoldson at pulsen dot se
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: SLES 9.3 64 bit
PHP Version: 5.1.4
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
I think I just fixed this in CVS. It would be great if you could grab
the next snapshot dated after this message and validate that it works.
Previous Comments:
[2006-07-11 04:44:45] john dot enevoldson at pulsen dot se
Hi,
Have done some more digging around and find bug 32800 and 32830
relating to odbc (not pdo) which is very similar to our original
problem - may give some clues...
Regards,
John.
[2006-07-10 12:17:19] john dot enevoldson at pulsen dot se
missed this bit :
(gdb) frame 3
#3 0x8027e936 in execute (op_array=0x805139e8) at
zend_vm_execute.h:92
92 if (EX(opline)-handler(execute_data
TSRMLS_CC) 0) {
/John
[2006-07-10 12:12:26] john dot enevoldson at pulsen dot se
Hi,
backtrace genereated for the segmentation fault using the 5.2 cvs:
(gdb) bt
#0 _zval_ptr_dtor (zval_ptr=0x3ffc280) at
/home/tje/php/php5.2-200607100830/Zend/zend_execute_API.c:393
#1 0x8021a356 in zend_do_fcall_common_helper_SPEC
(execute_data=0x3ffc750) at zend_execute.h:148
#2 0x8021a7e6 in ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
(execute_data=value optimized out) at zend_vm_execute.h:322
#3 0x8027e936 in execute (op_array=0x805139e8) at
zend_vm_execute.h:92
#4 0x801f5514 in zend_execute_scripts (type=8, retval=0x0,
file_count=3)
at /home/tje/php/php5.2-200607100830/Zend/zend.c:1110
#5 0x801b1f18 in php_execute_script
(primary_file=0x3ffece8)
at /home/tje/php/php5.2-200607100830/main/main.c:1748
#6 0x80280140 in main (argc=2, argv=0x3fff388) at
/home/tje/php/php5.2-200607100830/sapi/cli/php_cli.c:1097
(gdb)
Best regards,
John.
[2006-07-10 11:45:38] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php for *NIX and
http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2006-07-10 11:24:50] john dot enevoldson at pulsen dot se
Hi,
Have installed php5.2-latest.tar.gz but now get a segmentation fault
during the connect processing,
Regards,
John.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/38054
--
Edit this bug report at http://bugs.php.net/?id=38054edit=1
#38458 [Asn-Csd]: Fails to get values of fields following a MEMO type field in MS Access
ID: 38458
Updated by: [EMAIL PROTECTED]
Reported By: costas at meezon dot com
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP Prof
PHP Version: 5.1.4
Assigned To: wez
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fix will show up in the next PHP 5.2 snapshot at snaps.php.net.
Previous Comments:
[2006-09-22 22:26:38] johnc at inkjetinc dot com
I am seeing the same problem accessing MEMO fields in Visual FoxPro
using pdo/odbc in php 5.1.6. I was previusly using php 5.1.1 and did
not encounter this issue in that version (in php 5.1.1 I addeded pdo
maually from the pecl compiled sources).
[2006-08-16 14:48:48] costas at meezon dot com
I have teste with snapshot as suggested and get the exact same results
(version PHP Version 5.2.0RC2-dev)
Results:
doe|mm||nn2||
smith|xx||yy2||
doe|mm||nn2||
smith|xx||yy2||
doe|mm|120 main street|nn2|10006|
smith|xx|320 bway|yy2|10007|
[2006-08-15 06:41:12] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-08-15 00:11:36] costas at meezon dot com
Description:
I have an MS Access database and use PDO/ODBC. There are 2 MEMO type
columns (notes and notes2) in one table 'tblNotes'.
tblNotes structure
---
LastName - text,
notes - memo,
addr - text,
notes2 - memo
zip - text
I added 2 rows and manually populated all the columns with data. The
notes and notes2 have just a couple of characters each.
Problem:
-
When I use 'SELECT * from tblNotes' all rows are retrieved, but the
values for all non-MEMO type columns (which follow MEMO columns) are
null. This means addr and zip are NULL but LastName is correct.
If I explicitly name the columns in the SELECT I get the same result
(E.g. SELECT LastName, notes, addr, notes2, zip from tblNotes order by
LastName). This means addr and zip are NULL but LastName is correct.
Workaround:
If I move the notes and notes2 columns to the end, then all the values
are retrieved (E.g. SELECT LastName, addr, zip, notes, notes2 from
tblNotes order by LastName)
This is OK if you have just a few columns. Otherwise you have to type
them all in.
I am not sure if this is a PDO problem or ODBC.
Reproduce code:
---
?php
$tbl='tblNotes';
$user='';
$pass='';
$conn = DSN=mailing;Driver=Microsoft Access Driver;
try {
$dbh = new PDO(odbc:$conn, $user, $pass);
$cursor=$dbh-query(SELECT * from $tbl order by LastName);
foreach ($cursor as $row) {
$row=array_change_key_case($row, CASE_UPPER);
echo $row['LASTNAME'] . '|';
echo $row['NOTES'] . '|';
echo $row['ADDR'] . '|';
echo $row['NOTES2'] . '|';
echo $row['ZIP'] . '|';
echo \n;
}
echo \n;
$cursor1=$dbh-query(SELECT LastName, notes, addr, notes2, zip
from $tbl order by LastName);
foreach ($cursor1 as $row) {
$row=array_change_key_case($row, CASE_UPPER);
echo $row['LASTNAME'] . '|';
echo $row['NOTES'] . '|';
echo $row['ADDR'] . '|';
echo $row['NOTES2'] . '|';
echo $row['ZIP'] . '|';
echo \n;
}
echo \n;
$cursor2=$dbh-query(SELECT LastName, addr, zip, notes, notes2
from $tbl order by LastName);
foreach ($cursor2 as $row) {
$row=array_change_key_case($row, CASE_UPPER);
echo $row['LASTNAME'] . '|';
echo $row['NOTES'] . '|';
echo $row['ADDR'] . '|';
echo $row['NOTES2'] . '|';
echo $row['ZIP'] . '|';
echo \n;
}
} catch (PDOException $e) {
echo $e-getMessage();
}
$dbh = null;
?
Expected result:
For $cursor -- wrong result
doe|mm||nn||
smith|xx||yy||
For $cursor1 -- wrong result
doe|mm||nn||
smith|xx||yy||
For $cursor2 --- Correct result
doe|mm|120 main street|nn|10006|
smith|xx|320 bway|yy|10007|
Actual result:
--
See expected results above.
--
Edit this bug report at http://bugs.php.net/?id=38458edit=1
#38985 [Opn-Ctl]: Can't cast COM objects to boolean
ID: 38985
Updated by: [EMAIL PROTECTED]
Reported By: larry dot menard at rogers dot com
-Status: Open
+Status: Critical
Bug Type: COM related
Operating System: Windows XP, SP2
PHP Version: 5.2.0RC4
-Assigned To:
+Assigned To: ilia
New Comment:
I think this one liner will do the job, but haven't been able to verify
it:
Index: com_handlers.c
===
RCS file: /repository/php-src/ext/com_dotnet/com_handlers.c,v
retrieving revision 1.37
diff -u -p -r1.37 com_handlers.c
--- com_handlers.c 29 Apr 2006 18:45:29 - 1.37
+++ com_handlers.c 6 Oct 2006 12:03:31 -
@@ -539,7 +539,7 @@ static int com_object_cast(zval *readobj
return SUCCESS;
}
- return FAILURE;
+ return zend_std_cast_object_tostring(readobj, writeobj, type
TSRMLS_CC);
}
static int com_object_count(zval *object, long *count TSRMLS_DC)
cvs diff: Diffing tests
Previous Comments:
[2006-10-06 06:48:00] [EMAIL PROTECTED]
No idea why it was assigned to me.
I've never had win32 build env.
[2006-10-06 01:17:16] [EMAIL PROTECTED]
batting back to you Tony; between moving offices this last week and a
dead laptop I don't have a win32 build environment and won't have one
in time to get this fixed for 5.2.
As per our email discussion, I think the fix for this issue is to not
return failure from the COM object cast handler in the case that we
can't convert to variant bool, but to use regular PHP boolean cast at
that point (after trying variant bool conversion) and returning
success.
[2006-09-28 19:55:41] larry dot menard at rogers dot com
Description:
First of all, I'm usng RC5, not RC4 (RC5 is not in the list above).
Can't cast an object of type COM to boolean.
Reproduce code:
---
$dbc = new COM('WinNT://Domain'); var_dump((bool)$dbc);
Expected result:
bool(true)
Actual result:
--
Catchable fatal error: Object of class com could not be converted to
boolean
--
Edit this bug report at http://bugs.php.net/?id=38985edit=1
#39052 [Opn-Bgs]: pdo::query with show slave/master status
ID: 39052
Updated by: [EMAIL PROTECTED]
Reported By: xing at mac dot com
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.6
New Comment:
$link-setAttribute(PDO::ATTR_EMULATE_PREPARES, true);
Previous Comments:
[2006-10-05 20:34:58] xing at mac dot com
?php
$link = new PDO(mysql:host=127.0.0.1;port=3;,user,password);
$link-setAttribute (PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$link-setAttribute (PDO::MYSQL_ATTR_USE_BUFFERED_QUERY, TRUE);
$link-query(SET NAMES 'utf8');
try {
$link-query(show slave status);
echo good;
}
catch (PDOException $e) {
echo pre;
print_r($e);
echo /pre;
}
?
[2006-10-05 20:21:38] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc. If the script requires a
database to demonstrate the issue, please make sure it creates
all necessary tables, stored procedures etc.
Please avoid embedding huge scripts into the report.
[2006-10-05 20:09:14] xing at mac dot com
Just tried the 5.2cvs snapshot. Same result. No change.
[2006-10-05 19:36:29] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.2-win32-latest.zip
[2006-10-05 19:28:57] xing at mac dot com
Description:
PHP 5.1.6
Mysql 5.0.24a
I have tested using PDO::query for both show master status and show
slave status via tcp port and both bomb out with SQLSTATE[HY000]:
General error: 2030 This command is not supported in the prepared
statement protocol yet error.
Bug #36572 was suppoed to fix this but I just tested with php 5.1.6 and
the issue is still unresolved.
Reproduce code:
---
Execute
show slave status;
or
show master status
via pdo::query connected to server using tcp port.
Expected result:
Result set.
Actual result:
--
SQLSTATE[HY000]: General error: 2030 This command is not supported in
the prepared statement protocol yet
--
Edit this bug report at http://bugs.php.net/?id=39052edit=1
#38985 [Asn]: Can't cast COM objects to boolean
ID: 38985
Updated by: [EMAIL PROTECTED]
Reported By: larry dot menard at rogers dot com
Status: Assigned
Bug Type: COM related
Operating System: Windows XP, SP2
PHP Version: 5.2.0RC4
-Assigned To: wez
+Assigned To: tony2001
New Comment:
batting back to you Tony; between moving offices this last week and a
dead laptop I don't have a win32 build environment and won't have one
in time to get this fixed for 5.2.
As per our email discussion, I think the fix for this issue is to not
return failure from the COM object cast handler in the case that we
can't convert to variant bool, but to use regular PHP boolean cast at
that point (after trying variant bool conversion) and returning
success.
Previous Comments:
[2006-09-28 19:55:41] larry dot menard at rogers dot com
Description:
First of all, I'm usng RC5, not RC4 (RC5 is not in the list above).
Can't cast an object of type COM to boolean.
Reproduce code:
---
$dbc = new COM('WinNT://Domain'); var_dump((bool)$dbc);
Expected result:
bool(true)
Actual result:
--
Catchable fatal error: Object of class com could not be converted to
boolean
--
Edit this bug report at http://bugs.php.net/?id=38985edit=1
#38805 [Fbk]: PDO Truncates Text from SQL Server Text Data Type Field
ID: 38805 Updated by: [EMAIL PROTECTED] Reported By: gkrajci at arescorporation dot com Status: Feedback Bug Type: PDO related Operating System: Windows NT PBMA-WB2 5.2 build 37 PHP Version: 5.1.6 Assigned To: wez New Comment: I assume you're using ODBC? Previous Comments: [2006-09-13 15:40:37] [EMAIL PROTECTED] what PDO driver are you using? [2006-09-13 13:06:35] gkrajci at arescorporation dot com Description: When using PDO to retrieve text from a SQL Server text data type field the text is truncated when I display it on a Web page PDO Transcript length = 4096 (truncated) PEAR Transcript length = 6139(full text) Using SQL Server 2000 Reproduce code: --- $sql = SELECT title AS VideoTitle, transcript_text AS TranscriptText FROM video WHERE video_id = 324; $dbh = new PDO($pdo_dsn, $db_user, $db_password); $transcript_q = $dbh-query($sql); $transcript_rs = $transcript_q-fetch(); $pear_dsn = $db_type://$db_user:[EMAIL PROTECTED]/$db_name; require_once( 'DB.php' ); $db = DB::connect( $pear_dsn, true ); if ( DB::isError($db) ) die( $db-getMessage() ); $res = $db-query($sql); $row = $res-fetchRow(); Expected result: The text in TranscriptText to be the text and the same length. Actual result: -- See Description for this bug report. -- Edit this bug report at http://bugs.php.net/?id=38805edit=1
#30157 [Asn]: ftell() function does not use stream_tell()
ID: 30157
Updated by: [EMAIL PROTECTED]
Reported By: tendencies at free dot fr
Status: Assigned
Bug Type: Streams related
Operating System: *
PHP Version: 5CVS-2004-09-19 (dev)
Assigned To: pollita
New Comment:
I truly hope that this patch didn't get committed; it's not part of the
streams design and is fundamentally redundant.
I don't have time to make any further commentary than that; further
analysis of the user-stream case mentioned in this bug report is
required, but it certainly does not require making this kind of change
to the core.
Previous Comments:
[2005-06-16 17:22:20] [EMAIL PROTECTED]
Why did you need to add tell() function to the streams internals?
Because the original problem (stream_tell() is not used) looks like a
bug to me.
[2005-06-16 17:17:11] [EMAIL PROTECTED]
This tell patch
(http://tony2001.phpclub.net/dev/tmp/userstreamop_tell.diff) is
wrong; the position should be set implicitly when the stream is
opened, and be updated by the streams layer when it knows that it is
changed (as happens when you seek).
If you need to determine the current position, you simply need to seek
with a zero offset from the current position.
Why did you need to add tell() function to the streams internals?
[2005-06-16 00:54:11] [EMAIL PROTECTED]
Sara, IMO it's time to commit the patch into 5.1.
What do you think?
[2005-04-05 23:30:52] [EMAIL PROTECTED]
Seems that Wez doesn't have enough time to work on it anymore.
Sara, plz, take a look at this patch:
http://tony2001.phpclub.net/dev/tmp/userstreamop_tell.diff
The only problem I can see there is that all custom stream wrapper will
have to add appropriate entries too.
[2004-09-19 21:01:19] tendencies at free dot fr
Description:
For a test, I use wrapper_register() to register a new wrapper. For
information, I use PHP5 CVS and apache.
I want to create a wrapper and use ftell() to return an integer
different from the length of the string (normal comportement). I
implement the method stream_tell() and call ftell(), but surprise, this
function don't use the method stream_tell().
Reproduce code:
---
?php
class fileWrapper {
var $fp;
function stream_open($path, $mode, $options, $opened_path){
$url = parse_url($path);
$this-fp = fopen($url[host], $mode);
return true;
}
function stream_write($data){
return fwrite($this-fp, $data);
}
function stream_tell(){
echo debug message;
return ftell($this-fp);
}
function stream_close(){
return fclose($this-fp);
}
}
stream_wrapper_register(test, fileWrapper);
$fp = fopen(test://file.txt, w+);
fwrite($fp, test);
echo I test the echo debug in stream_tell() method:;
echo ftell($fp).\n;
fclose($fp);
?
Expected result:
Use the code above, I write a debug message in the method
stream_tell() but no message is writted in my screen, just this :
I test the echo debug in stream_tell() method:0
I think that it's a bug but if not, all my apologies.
--
Edit this bug report at http://bugs.php.net/?id=30157edit=1
#30157 [Asn]: ftell() function does not use stream_tell()
ID: 30157 Updated by: [EMAIL PROTECTED] Reported By: tendencies at free dot fr Status: Assigned Bug Type: Streams related Operating System: * PHP Version: 5CVS-2004-09-19 (dev) Assigned To: pollita New Comment: (PS: I got here via Bug #37096) Previous Comments: [2006-07-26 16:42:25] [EMAIL PROTECTED] I truly hope that this patch didn't get committed; it's not part of the streams design and is fundamentally redundant. I don't have time to make any further commentary than that; further analysis of the user-stream case mentioned in this bug report is required, but it certainly does not require making this kind of change to the core. [2005-06-16 17:22:20] [EMAIL PROTECTED] Why did you need to add tell() function to the streams internals? Because the original problem (stream_tell() is not used) looks like a bug to me. [2005-06-16 17:17:11] [EMAIL PROTECTED] This tell patch (http://tony2001.phpclub.net/dev/tmp/userstreamop_tell.diff) is wrong; the position should be set implicitly when the stream is opened, and be updated by the streams layer when it knows that it is changed (as happens when you seek). If you need to determine the current position, you simply need to seek with a zero offset from the current position. Why did you need to add tell() function to the streams internals? [2005-06-16 00:54:11] [EMAIL PROTECTED] Sara, IMO it's time to commit the patch into 5.1. What do you think? [2005-04-05 23:30:52] [EMAIL PROTECTED] Seems that Wez doesn't have enough time to work on it anymore. Sara, plz, take a look at this patch: http://tony2001.phpclub.net/dev/tmp/userstreamop_tell.diff The only problem I can see there is that all custom stream wrapper will have to add appropriate entries too. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/30157 -- Edit this bug report at http://bugs.php.net/?id=30157edit=1
#38182 [Asn-WFx]: PDO::ATTR_TIMEOUT can be set but not retrieved
ID: 38182 Updated by: [EMAIL PROTECTED] Reported By: auroraeosrose at gmail dot com -Status: Assigned +Status: Wont fix Bug Type: PDO related Operating System: WinXPSP2 PHP Version: 5CVS-2006-07-21 (snap) Assigned To: wez New Comment: as a matter of fact, this option is write-only; setting it simply maps to a call to: int sqlite3_busy_timeout(sqlite3*, int ms); there is no corresponding API for returning this value. Now, IMO, there is no *good* reason that I can think of where you need this information. The default is 60 seconds, which is a decent default. Previous Comments: [2006-07-21 20:56:19] auroraeosrose at gmail dot com Description: sqlite (v. 3) driver $handle-setAttribute(PDO::ATTR_TIMEOUT, 3); works just fine but $handle-getAttribute(PDO::ATTR_TIMEOUT); creates Warning: PDO::getAttribute(): SQLSTATE[IM001]: Driver does not support this function: driver does not support that attribute maybe it's just me - but if you can set the attribute shouldn't you be able to retrieve it as well? -- Edit this bug report at http://bugs.php.net/?id=38182edit=1
#38103 [Asn-Bgs]: PDO::FETCH_INTO fails w/extraneous param
ID: 38103 Updated by: [EMAIL PROTECTED] Reported By: jeffmlevy+phpbugs at gmail dot com -Status: Assigned +Status: Bogus Bug Type: PDO related Operating System: Debian GNU Linux PHP Version: 5.1.4 Assigned To: wez New Comment: RTM. At no point does it tell you that you can use FETCH_INFO with fetchAll(). Think about what that means. Previous Comments: [2006-07-14 10:12:39] jeffmlevy+phpbugs at gmail dot com Description: Note: Mysql PDO. PDO fails with error when calling fetchAll() w/PDO::FETCH_INTO. Implicit call to setFetchMode(PDO::FETCH_INTO, $oObject) passes the test, however. Reproduce code: --- $stmt = $dbh-prepare(call data_loader()); $stmt-setFetchMode(PDO::FETCH_INTO, $this); $stmt-fetchAll(); results in proper assignment of return vars to object props. BUT: $stmt = $dbh-prepare(call data_loader()); $stmt-fetchAll(PDO::FETCH_INTO, $this); calling with $this results in: PDOStatement::fetchAll(): SQLSTATE[HY000]: General error: Extraneous additional parameters calling without $this results in PDOStatement::fetchAll(): SQLSTATE[HY000]: General error: No fetch-into object specified. Expected result: Expect class properties to be properly populated. Actual result: -- Error thrown. Could be lack of documenatation?? -- Edit this bug report at http://bugs.php.net/?id=38103edit=1
#37319 [Asn-Fbk]: MySQL server has gone away, with PDO::ATTR_PERSISTENT = true
ID: 37319
Updated by: [EMAIL PROTECTED]
Reported By: j8859 at clix dot pt
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Linux Slackware 10.2
PHP Version: 5.1.3
Assigned To: wez
New Comment:
Try following the tips here:
http://netevil.org/node.php?uuid=444a6017-0548-2459-2943-44a601714d58
Previous Comments:
[2006-05-06 09:52:22] j8859 at clix dot pt
It occurs also with PHP 5.1.4.
[2006-05-05 02:40:34] j8859 at clix dot pt
Description:
This error also occurs with PHP 5.1.2, but with more frequency than
with 5.1.3.
It occurs only if I use PDO::ATTR_PERSISTENT = true, and it never
occurs with PDO::ATTR_PERSISTENT = false.
I have several databases in MySQL, several programs in PHP some using
the classic MySQL functions, others using MySQLi, and one using PDO.
This is the one which produces errors.
The MySQL version is 5.0.18. Apache/1.3.34.
If I do a MySQL Flush Tables, the error stops.
With PHP 5.1.2 I also need to do an Apache restart to get the error
stop occurring.
The error never occurred with few MySQL tables opened.
I do a diary crontab backup with mysqldump, over the night, and in the
morning there are about 220 opened tables.
Then, when I use my PDO application, I start getting MySQL server has
gone away errors.
I changed to PDO::ATTR_PERSISTENT = false and the error never
happened.
I changed back to PDO::ATTR_PERSISTENT = true and the error returned.
I know this can be difficult for you to reproduce it, because it is not
a deterministic error, but I'm sure there is an error.
Reproduce code:
---
$bd = new PDO();
$query = SELECT * FROM mytable;
$inst = $this-prepare($query);
if(!$inst) die (ERROR: . $query . , . __FILE__ . , .
__LINE__);
if(!$inst-execute()) { $inst-closeCursor(); return; }
while($reg = $inst-fetch(PDO::FETCH_ASSOC)) {
// Process $reg
}
$inst-closeCursor();
$bd = null;
--
Edit this bug report at http://bugs.php.net/?id=37319edit=1
#37497 [Bgs]: Nothing works
ID: 37497
Updated by: [EMAIL PROTECTED]
Reported By: jwagoner at seminolesheriff dot org
Status: Bogus
Bug Type: PDO related
Operating System: Windows
PHP Version: 5.1.4
New Comment:
Good riddance.
Previous Comments:
[2006-05-18 13:40:24] [EMAIL PROTECTED]
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions. Due to the volume
of reports we can not explain in detail here why your report is not
a bug. The support channels will be able to provide an explanation
for you.
Thank you for your interest in PHP.
[2006-05-18 13:29:44] jwagoner at seminolesheriff dot org
Description:
PDO does not work on Windows.
Reproduce code:
---
Any of these:
$dbconn = new PDO('mssql:host=localhost;dbname=blah', 'blah', 'blah');
$dbconn = new PDO('dblib:host=localhost;dbname=blah', 'blah', 'blah');
$dbconn = new PDO('odbc:testodbc', 'blah', 'blah');
$dbconn = new PDO('odbc:testodbc');
Expected result:
Umm.. for it to connect.
Actual result:
--
A could not find driver error. PHP file has every single one..
extension=php_pdo.dll
extension=php_pdo_mssql.dll
extension=php_pdo_odbc.dll
And nothing works. Every other DLL works fine. I can't use dl() because
windows sucks.
No documentation what-so-ever helps windows users. I would love not to
use this piece of crap, but don't really have a choice. At this point
I'm about to ditch PDO.
--
Edit this bug report at http://bugs.php.net/?id=37497edit=1
#37363 [Opn]: Doesn't compile with PDO-PHP
ID: 37363 Updated by: [EMAIL PROTECTED] Reported By: fpazzatura at email dot it Status: Open Bug Type: PDO related Operating System: Ubuntu Linux (Breezy Badger) PHP Version: 5.1.5CVS New Comment: What does mysql_config output on your system? Previous Comments: [2006-05-08 14:23:13] fpazzatura at email dot it The version of my libmysql package is 4.1.12, the my compiler is gcc 4.0.1 With same libraries and compiler, PHP 5.1.3 compiles greetly... [2006-05-08 13:20:45] [EMAIL PROTECTED] When version of MySQL library are you compiling pdo_mysql against? [2006-05-08 08:35:54] fpazzatura at email dot it Description: my config flags ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --disable-cgi --with-config-file-path=/etc --enable-libcc --disable-short-tags --without-pcre-regex --with-zlib --with-bz2 --with-gd --with-ming --with-pdo-mysql --without-pdo-sqlite --without-sqlite --disable-tokenizer --without-pear already with apache2 and no cli (the error with loading in apache2) There's the error: ext/pdo_mysql/pdo_mysql.o: In function `zm_info_pdo_mysql': pdo_mysql.c:(.text+0x109): undefined reference to `mysql_get_client_info' ext/pdo_mysql/mysql_driver.o: In function `_pdo_mysql_error': mysql_driver.c:(.text+0xd6): undefined reference to `mysql_stmt_errno' mysql_driver.c:(.text+0x11f): undefined reference to `mysql_error' mysql_driver.c:(.text+0x145): undefined reference to `mysql_stmt_sqlstate' mysql_driver.c:(.text+0x196): undefined reference to `mysql_errno' mysql_driver.c:(.text+0x24a): undefined reference to `mysql_sqlstate' mysql_driver.c:(.text+0x266): undefined reference to `mysql_error' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_closer': mysql_driver.c:(.text+0x37a): undefined reference to `mysql_close' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_doer': mysql_driver.c:(.text+0x402): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x410): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_last_insert_id': mysql_driver.c:(.text+0x491): undefined reference to `mysql_insert_id' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_quoter': mysql_driver.c:(.text+0x518): undefined reference to `mysql_real_escape_string' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_get_attribute': mysql_driver.c:(.text+0x5ee): undefined reference to `mysql_stat' mysql_driver.c:(.text+0x63f): undefined reference to `mysql_get_host_info' mysql_driver.c:(.text+0x651): undefined reference to `mysql_get_client_info' mysql_driver.c:(.text+0x68b): undefined reference to `mysql_get_server_info' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_set_attribute': mysql_driver.c:(.text+0x79c): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x82e): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_begin': mysql_driver.c:(.text+0x892): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x8d6): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_commit': mysql_driver.c:(.text+0x932): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x976): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_rollback': mysql_driver.c:(.text+0x9d2): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0xa16): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_preparer': mysql_driver.c:(.text+0xacd): undefined reference to `mysql_get_server_version' mysql_driver.c:(.text+0xb1f): undefined reference to `mysql_stmt_init' mysql_driver.c:(.text+0xb3e): undefined reference to `mysql_stmt_prepare' mysql_driver.c:(.text+0xb61): undefined reference to `mysql_stmt_param_count' mysql_driver.c:(.text+0xc47): undefined reference to `mysql_errno' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_handle_factory': mysql_driver.c:(.text+0xde5): undefined reference to `mysql_init' mysql_driver.c:(.text+0x122f): undefined reference to `mysql_options' mysql_driver.c:(.text+0x12c3): undefined reference to `mysql_options' mysql_driver.c:(.text+0x133f): undefined reference to `mysql_options' mysql_driver.c:(.text+0x13c3): undefined reference to `mysql_options' mysql_driver.c:(.text+0x149e): undefined reference to `mysql_options' mysql_driver.c:(.text+0x1574): undefined reference to `mysql_real_connect' mysql_driver.c:(.text+0x1606): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x164d): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_statement.o: In
#37363 [Opn-Fbk]: Doesn't compile with PDO-PHP
ID: 37363 Updated by: [EMAIL PROTECTED] Reported By: fpazzatura at email dot it -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Ubuntu Linux (Breezy Badger) PHP Version: 5.1.5CVS Previous Comments: [2006-05-09 12:18:04] [EMAIL PROTECTED] What does mysql_config output on your system? [2006-05-08 14:23:13] fpazzatura at email dot it The version of my libmysql package is 4.1.12, the my compiler is gcc 4.0.1 With same libraries and compiler, PHP 5.1.3 compiles greetly... [2006-05-08 13:20:45] [EMAIL PROTECTED] When version of MySQL library are you compiling pdo_mysql against? [2006-05-08 08:35:54] fpazzatura at email dot it Description: my config flags ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --mandir=/usr/share/man --disable-cgi --with-config-file-path=/etc --enable-libcc --disable-short-tags --without-pcre-regex --with-zlib --with-bz2 --with-gd --with-ming --with-pdo-mysql --without-pdo-sqlite --without-sqlite --disable-tokenizer --without-pear already with apache2 and no cli (the error with loading in apache2) There's the error: ext/pdo_mysql/pdo_mysql.o: In function `zm_info_pdo_mysql': pdo_mysql.c:(.text+0x109): undefined reference to `mysql_get_client_info' ext/pdo_mysql/mysql_driver.o: In function `_pdo_mysql_error': mysql_driver.c:(.text+0xd6): undefined reference to `mysql_stmt_errno' mysql_driver.c:(.text+0x11f): undefined reference to `mysql_error' mysql_driver.c:(.text+0x145): undefined reference to `mysql_stmt_sqlstate' mysql_driver.c:(.text+0x196): undefined reference to `mysql_errno' mysql_driver.c:(.text+0x24a): undefined reference to `mysql_sqlstate' mysql_driver.c:(.text+0x266): undefined reference to `mysql_error' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_closer': mysql_driver.c:(.text+0x37a): undefined reference to `mysql_close' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_doer': mysql_driver.c:(.text+0x402): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x410): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_last_insert_id': mysql_driver.c:(.text+0x491): undefined reference to `mysql_insert_id' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_quoter': mysql_driver.c:(.text+0x518): undefined reference to `mysql_real_escape_string' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_get_attribute': mysql_driver.c:(.text+0x5ee): undefined reference to `mysql_stat' mysql_driver.c:(.text+0x63f): undefined reference to `mysql_get_host_info' mysql_driver.c:(.text+0x651): undefined reference to `mysql_get_client_info' mysql_driver.c:(.text+0x68b): undefined reference to `mysql_get_server_info' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_set_attribute': mysql_driver.c:(.text+0x79c): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x82e): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_begin': mysql_driver.c:(.text+0x892): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x8d6): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_commit': mysql_driver.c:(.text+0x932): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0x976): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_rollback': mysql_driver.c:(.text+0x9d2): undefined reference to `mysql_real_query' mysql_driver.c:(.text+0xa16): undefined reference to `mysql_affected_rows' ext/pdo_mysql/mysql_driver.o: In function `mysql_handle_preparer': mysql_driver.c:(.text+0xacd): undefined reference to `mysql_get_server_version' mysql_driver.c:(.text+0xb1f): undefined reference to `mysql_stmt_init' mysql_driver.c:(.text+0xb3e): undefined reference to `mysql_stmt_prepare' mysql_driver.c:(.text+0xb61): undefined reference to `mysql_stmt_param_count' mysql_driver.c:(.text+0xc47): undefined reference to `mysql_errno' ext/pdo_mysql/mysql_driver.o: In function `pdo_mysql_handle_factory': mysql_driver.c:(.text+0xde5): undefined reference to `mysql_init' mysql_driver.c:(.text+0x122f): undefined reference to `mysql_options' mysql_driver.c:(.text+0x12c3): undefined reference to `mysql_options' mysql_driver.c:(.text+0x133f): undefined reference to `mysql_options' mysql_driver.c:(.text+0x13c3): undefined reference to `mysql_options' mysql_driver.c:(.text+0x149e): undefined reference to `mysql_options' mysql_driver.c:(.text+0x1574): undefined reference to `mysql_real_connect' mysql_driver.c:(.text+0x1606): undefined reference to
#37361 [Opn-Bgs]: prepare statement alter the datatype of a parameter
ID: 37361
Updated by: [EMAIL PROTECTED]
Reported By: axel dot azerty at laposte dot net
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Fedora Core 5 - Linux 2.6.16
PHP Version: 5.1.4
New Comment:
This is expected behaviour.
Previous Comments:
[2006-05-08 13:05:34] smlerman at gmail dot com
bindParam and bindValue treat the parameter as a string by default,
which means the value has special characters escaped and the entire
value quoted. Your code produces COALESCE(MAX('id_board'),0), which is
probably not what you want. You'll most likely need to place the field
name directly in the query instead of trying to bind it as if it were
normal data.
[2006-05-08 07:01:03] axel dot azerty at laposte dot net
Description:
The prepared statement in PDO seems to lost or to have its type
altered.
When typing a 'SELECT COALESCE(MAX(field),0) FROM table' under
postgresql shell, no problem.
When using this query as is in PHP (with PDO), no problem.
When trying SELECT COALESCE(MAX(?),0) FROM table as a prepared
statement, the execution fails.
Replacing MAX(?),0 by MAX(?),'0' solves the problem, but the
returned value is a string, and not an integer.
Reproduce code:
---
$stmt = $dbh-prepare(SELECT COALESCE(MAX(?),0) FROM board);
$stmt-bindParam(1,$fld);
$fld = id_board;
if(!$stmt-execute()) print_r($stmt-errorInfo());
Expected result:
The expected result is 0 , in the case or the table is empty or the
number of lines in the table.
Actual result:
--
The statement-errorInfo() returns :
Array
(
[0] = 42804
[1] = 7
[2] = ERREUR: Les COALESCE types text et integer ne peuvent pas
correspondre
)
In english : the COALESCE types text and interger can't match.
--
Edit this bug report at http://bugs.php.net/?id=37361edit=1
#35272 [NoF-Csd]: PDO-prepare() (mysql) causes apache 1.3 to crash
ID: 35272
Updated by: [EMAIL PROTECTED]
Reported By: alexdow__ at hotmail dot com
-Status: No Feedback
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.1.0RC5
New Comment:
Upgrade to latest release.
Previous Comments:
[2005-11-26 01:00:28] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2005-11-18 09:35:41] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to Open. Thank you for helping
us make PHP better.
[2005-11-18 09:07:50] alexdow__ at hotmail dot com
$query = INSERT INTO users
(username,email,country,city,password,creation_date,status)
VALUES
(:username,:email,:country,:city,:password,NOW(),1);
here is a query I use
[2005-11-18 08:17:11] alexdow__ at hotmail dot com
Description:
Preparing a query on MySQL 5.0 using PDO results in Apache crashing.
Reproduce code:
---
$pdo = new
PDO('mysql:host=localhost;dbname=somedb','user','pass',array(PDO::ATTR_PERSISTENT
= true));
$statement = $pdo-prepare($argQuery);
Expected result:
I expect $statement to be a proper PDOStatement object.
Actual result:
--
Actual result is Apache crashing. I'm not sure how to generate
backtraces in windows other than debugging through VS.NET, if you want
that.
--
Edit this bug report at http://bugs.php.net/?id=35272edit=1
#36449 [Bgs]: Procedure call + PDO::ATTR_PERSISTENT = true
ID: 36449
Updated by: [EMAIL PROTECTED]
Reported By: brice dot joly at free dot fr
Status: Bogus
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.2.0-dev
New Comment:
Please read my comments again, carefully.
Previous Comments:
[2006-04-30 10:43:58] brice dot joly at free dot fr
Some quick clarification: the problem occurs even with non-prepared
code:
$dbh = new PDO('mysql:host=localhost;dbname=test', 'user', 'password',
array(PDO::ATTR_PERSISTENT = true);
foreach ($dbh-query(CALL simpleTest()) as $row) {
print_r($row);
}
$arr = $dbh-errorInfo();
print_r($arr);
So I'm afraid the problem is not directly linked with the native
prepared statement API, though the people at that conference might know
better.
[2006-04-30 01:06:53] [EMAIL PROTECTED]
Not a PHP bug; you cannot use CALL with the native prepared statement
API in mySQL.
Use the latest snapshot or PHP 5.1.3 (being released any day now) and
follow the advice in:
http://netevil.org/node.php?nid=795
[2006-04-27 10:38:38] brice dot joly at free dot fr
Not yet fixed in build of Apr 27 2006 08:15:12, above code still fails.
[2006-04-17 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-04-09 07:54:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
The next snapshot dated after this message likely fixes this.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/36449
--
Edit this bug report at http://bugs.php.net/?id=36449edit=1
#37037 [Opn-Ana]: pgsql: Can't access result returned from an INSERT
ID: 37037
Updated by: [EMAIL PROTECTED]
Reported By: shadda at gmail dot com
-Status: Open
+Status: Analyzed
Bug Type: PDO related
Operating System: Debian 3.1
PHP Version: 5.1.3RC2
New Comment:
The issue related to native prepared statements not describing that
magical result set.
Workaround:
$stmt = $db-prepare(insert into test_table default values, array(
PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT = true));
$stmt-execute();
print_r($stmt-fetchAll());
Previous Comments:
[2006-04-11 10:36:53] shadda at gmail dot com
Just a quick note -- in the above insert statement, the table should be
'test_table'
[2006-04-11 10:30:53] shadda at gmail dot com
Description:
I'm using PostgreSQL 8.1.2, on Debian Sid. In my database, I have a
table with a RULE on inserts...
CREATE RULE test_rule AS
ON INSERT TO test_table
DO ALSO
SELECT NEW.id;
When a new row is inserted to this table, it returns the ID (currval)
of the new row. This works from PSQL, DBI (perl), and JDBC, aswell as
the standard Pgsql extension in PHP.
From PDO, however, when calling PDOStatement::Fetch() after an insert,
only an empty array is returned, and not the resultset I was expecting.
Reproduce code:
---
create table test_table ( id serial primary key );
create rule test_rule as on insert to test_table do also select
new.id;
[EMAIL PROTECTED]:/$ php -r '
$db = new
PDO(pgsql:host=localhost;user=xoom;password=1914;dbname=general);
$q = $db-query(insert into foo default values);
var_dump($q-fetch());
'
Expected result:
array(2) {
[0]=
string(2) 10
[id]=
string(2) 10
}
Actual result:
--
array(0) {
}
--
Edit this bug report at http://bugs.php.net/?id=37037edit=1
#36128 [Opn-Sus]: Interbase PDO
ID: 36128
Updated by: [EMAIL PROTECTED]
Reported By: michael at bluemoon dot com
-Status: Open
+Status: Suspended
Bug Type: PDO related
Operating System: Linux/Windows
PHP Version: 5.1.2
Previous Comments:
[2006-04-09 07:48:28] [EMAIL PROTECTED]
Looking for a firebird maintainer.
[2006-01-25 17:08:02] michael at bluemoon dot com
To amend my earlier problem description, it appears that I CAN issue
the SELECT query shown in my previous example successfully. However,
it appears that I cannot retrieve values from TIMESTAMP-type columns.
If I substitute SELECT MY_TIMESTAMP_FIELD FROM MY_TABLE for the query
in my original code, it will execute without throwing an exception, but
the value returned is empty (null). The result I am expecting is an
integer (Unix timestamp) value.
I don't know if this constitutes a 'bug' or if I am simply not going
about this the right way. I have tried many of the various
permutations for fetching results as shown in the PDO documentation,
but nothing seems to work.
Is there a way to fetch TIMESTAMP values using the Firebird/Interbase
PDO driver?
[2006-01-23 10:51:33] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-23 02:21:25] michael at bluemoon dot com
Description:
Exception thrown when issuing SELECT query using PDO driver
for Firebird/Interbase. Database Server runs Interbase 7.5.x
(Linux).
Problem occurs with PHP 5.1.2 running in both Linux/Apache 2
and Windows 2000/IIS environments.
Tried running PHP alternately with Interbase 6 and 7.5 Run-
time Client Libraries on each platform; same problem.
Native PHP Firebird/Interbase functions (e.g., ibase_connect
(), etc.) functions work fine in same environments used to
test PDO functions.
Confirmed DSN string used in my PDO connection function is
correct by testing PDO::ATTR_CONNECTION_STATUS attribute;
value returned is 1.
Reproduce code:
---
try {
$dbh = new PDO($dsn, $user, $password, array(
PDO::ATTR_PERSISTENT = true
));
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $dbh-prepare(SELECT Count(*) FROM MY_TABLE);
$stmt-execute();
$row = $stmt-fetch(PDO::FETCH_NUM);
$stmt = null;
echo $row[0];
}
catch (PDOException $e) {
die $e-getMessage();
}
Expected result:
Should output integer value result from SELECT query to screen
Actual result:
--
Outputs the following error:
SQLSTATE[HY000]: General error: -804 Dynamic SQL Error SQL
error code = -804 Incorrect values within SQLDA structure
--
Edit this bug report at http://bugs.php.net/?id=36128edit=1
#35552 [Asn-Csd]: access violation on any invalid odbc query
ID: 35552
Updated by: [EMAIL PROTECTED]
Reported By: humbads at alum dot mit dot edu
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-12-14 (snap)
Assigned To: wez
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fix will be in 5.1.4
Previous Comments:
[2005-12-23 12:55:25] markus at fischer dot name
I'm expiriencing the same behaviour with pdo_odbc and the M$ Access
Driver. I can verify this with this snapshot:
php5.1-win32-200512231130.zip
My testcase is:
$sDsn = 'odbc:driver={Microsoft Access Driver
(*.mdb)};Dbq=beispieldatenbank.mdb;';
$oPdo = new PDO($sDsn);
$oPdo-query('SELEC * FROM ADDRESSES');
[2005-12-14 09:11:23] humbads at alum dot mit dot edu
This one still gives an exception, but it is different from before.
The call stack is one thousand deep. I'm using snapshot
php5.1-win32-200512140730.zip.
Unhandled exception at 0x005f1164 (php_pdo_odbc.dll) in php-cgi.exe:
0xC005: Access violation writing location 0x0012.
php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e338,
_pdo_stmt_t * stmt=0x0071e850, void * statement=0x, char *
what=0x005f3194, const char * file=0x005f31cc, int line=202, void * * *
tsrm_ls=0x00324090) Line 101 + 0x7 C
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e338,
const char * sql=0x0071e510, long sql_len=13, _pdo_stmt_t *
stmt=0x0071e850, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00324090) Line 202 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e4a0, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e510, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
php5ts.dll!10018d52()
php5ts.dll!100b4b32()
php5ts.dll!10018765()
php5ts.dll!100186e5()
php5ts.dll!10008d52()
... ... REPEATS MANY TIMES
php5ts.dll!100a7b94()
php5ts.dll!10002e2d()
msvcrt.dll!_free() + 0xc3
[EMAIL PROTECTED]() + 0x130
00300030()
[EMAIL PROTECTED]() + 0x25
odbc32.dll!_MPLeaveCriticalSection() + 0x17
0012fa34()
[EMAIL PROTECTED]() + 0x96
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e338,
const char * sql=0x0071e510, long sql_len=13, _pdo_stmt_t *
stmt=0x0071e850, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00324090) Line 202 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e4a0, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e510, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
php5ts.dll!10018d52()
php5ts.dll!100b4b32()
php5ts.dll!10018765()
php5ts.dll!100186e5()
php5ts.dll!10008d52()
[2005-12-14 06:02:19] [EMAIL PROTECTED]
I made an adjustment to the way that we pull out the error information;
I'm not sure that it will have resolved this particular issue, but it's
worth trying it out while you're checking to see if #35620 is fixed.
[2005-12-05 18:54:18] humbads at alum dot mit dot edu
This is with the latest snapshot release:
php5.1-win32-200512051530.zip
Here is the stack trace:
[EMAIL PROTECTED]() + 0x6a
[EMAIL PROTECTED]() + 0x120
[EMAIL PROTECTED]() + 0xaa
php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e6c8,
_pdo_stmt_t * stmt=0x0071ebb8, void * statement=0x, char *
what=0x005f3194, const char * file=0x005f31cc, int line=175, void * * *
tsrm_ls=0x00323f68) Line 82C
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e6c8,
const char * sql=0x0071e878, long sql_len=13, _pdo_stmt_t *
stmt=0x0071ebb8, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00323f68) Line 175 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e808, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e878, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x0012fb38, void * * * tsrm_ls=0x00323f68) Line 192 +
0x35C
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER
#35793 [Opn]: General error: 2050
ID: 35793 Updated by: [EMAIL PROTECTED] Reported By: deadman_great at mail dot ru Status: Open Bug Type: PDO related Operating System: RH Fedora Core 2 PHP Version: 5CVS-2005-12-25 (snap) Assigned To: Wez New Comment: Please read this blog entry and see if following the advice there helps: http://netevil.org/node.php?nid=795 (you'll want to upgrade to PHP 5.1.3 or a current snapshot first). Previous Comments: [2006-04-17 17:04:04] [EMAIL PROTECTED] You need to change the bug status back to Open if the issue still occurs. The bug has been suspended by a cron script because it was still in state Feedback. I re-opened the bug for you. [2006-04-17 16:56:30] email at steffenweber dot net You must be kidding? :-( [2006-04-17 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-04-09 15:31:01] email at steffenweber dot net I´ve tried php5.1-200604091430.tar.bz2 and the error is still there. [2006-04-09 07:39:25] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Try the next snapshot dated after this message. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35793 -- Edit this bug report at http://bugs.php.net/?id=35793edit=1
#35793 [Opn-Fbk]: General error: 2050
ID: 35793 Updated by: [EMAIL PROTECTED] Reported By: deadman_great at mail dot ru -Status: Open +Status: Feedback Bug Type: PDO related Operating System: RH Fedora Core 2 PHP Version: 5CVS-2005-12-25 (snap) Assigned To: Wez Previous Comments: [2006-04-30 00:56:35] [EMAIL PROTECTED] Please read this blog entry and see if following the advice there helps: http://netevil.org/node.php?nid=795 (you'll want to upgrade to PHP 5.1.3 or a current snapshot first). [2006-04-17 17:04:04] [EMAIL PROTECTED] You need to change the bug status back to Open if the issue still occurs. The bug has been suspended by a cron script because it was still in state Feedback. I re-opened the bug for you. [2006-04-17 16:56:30] email at steffenweber dot net You must be kidding? :-( [2006-04-17 01:00:01] php-bugs at lists dot php dot net No feedback was provided for this bug for over a week, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to Open. [2006-04-09 15:31:01] email at steffenweber dot net I´ve tried php5.1-200604091430.tar.bz2 and the error is still there. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35793 -- Edit this bug report at http://bugs.php.net/?id=35793edit=1
#36228 [Asn-Bgs]: Loosing connection to db while executing 2 Multi-Statements requests with PDO
ID: 36228
Updated by: [EMAIL PROTECTED]
Reported By: antleclercq at online dot fr
-Status: Assigned
+Status: Bogus
Bug Type: PDO related
Operating System: Ubuntu Linux (breezy)
PHP Version: 5.1.2
Assigned To: wez
New Comment:
If you're executing multi-statement queries, you must use
PDO::prepare(), PDOStatement::execute() and PDOStatement::nextRowset().
Previous Comments:
[2006-03-01 12:57:02] antleclercq at online dot fr
Hi,
Any update ?
Thanks,
Antoine
[2006-01-31 17:03:24] antleclercq at online dot fr
Hello Tony,
It looks like it returns only the number of affected rows for the first
statement...
The affected rows for the next statements don't seem to be counted.
Also : if you have an error in your first statement, you get an error,
but if the error is in one of the next statements, these are not
reported.
Hmmm... I don't know really what I would expect to get as return value
from a multi-query... Certainly a sum of all the affected rows or
better... an array with that info on each statement.
Antoine
[2006-01-31 15:55:42] [EMAIL PROTECTED]
Just curious: what do you expect to get as the result of these
multi-statement?
PDO::exec returns number of rows expected. Since you're effectively
executing two queries - what do you expect to get?
What if one of the queries succeeds and another one fails?
[2006-01-31 15:12:57] antleclercq at online dot fr
Description:
Hello,
Executing 2 multi-statement queries gives you the following error :
2013 - Lost connection to MySQL server during query
I reproduced this error using 5.1.0RC3 and 5.1.2.
My MySQL version is 4.1.12, and I have the right MySQL / PDO
connector.
Thanks,
Antoine
Reproduce code:
---
?php
$dbh = new PDO(mysql:dbname=karibou;host=localhost, user,
password);
try {
$qry = DELETE FROM addressbook_address WHERE profile_id=2 ; \n;
$qry .= DELETE FROM addressbook_phone WHERE profile_id=2 ; \n;
//No error
$dbh-exec($qry);
//The folowing line displays : Array ( [0] = 0 )
print_r($dbh-errorInfo());
//This second exec statement produces the error : Lost connection to
MySQL server during query
$dbh-exec($qry);
//The following line displays : Array ( [0] = HY000 [1] = 2013 [2]
= Lost connection to MySQL server during query )
print_r($dbh-errorInfo());
} catch (PDOException $e) {
print $e-getMessage();
die();
}
?
Expected result:
None of the exec should return an error.
Actual result:
--
The second exec returns a 2013 error (Lost connection...).
Array ( [0] = HY000 [1] = 2013 [2] = Lost connection to MySQL server
during query )
--
Edit this bug report at http://bugs.php.net/?id=36228edit=1
#36449 [Opn-Bgs]: Procedure call + PDO::ATTR_PERSISTENT = true
ID: 36449
Updated by: [EMAIL PROTECTED]
Reported By: brice dot joly at free dot fr
-Status: Open
+Status: Bogus
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.2.0-dev
New Comment:
Not a PHP bug; you cannot use CALL with the native prepared statement
API in mySQL.
Use the latest snapshot or PHP 5.1.3 (being released any day now) and
follow the advice in:
http://netevil.org/node.php?nid=795
Previous Comments:
[2006-04-27 10:38:38] brice dot joly at free dot fr
Not yet fixed in build of Apr 27 2006 08:15:12, above code still fails.
[2006-04-17 01:00:01] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to Open.
[2006-04-09 07:54:37] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
The next snapshot dated after this message likely fixes this.
[2006-02-18 21:55:19] brice dot joly at free dot fr
Description:
When calling a procedure from PDO with PDO::ATTR_PERSISTENT = true, I
have a very strange behaviour when refreshing the page: on odd tries it
works as expected, on even ones PDO makes the call, then loses
connection while retrieving the result. Direct and prepared call both
produce the same behaviour. Note that the call is actually ran by MySQL
in both cases (appears in the query log).
When switching PDO::ATTR_PERSISTENT to false all works as expected.
Running the test with PHP CLI works fine. I run PHP (tested with
snapshot of 17 Feb 2006, 5.1.3-dev, had the same problem with 5.1.2) as
a module, Apache 2.0.52, MySQL 5.0.18.
Reproduce code:
---
// MySQL Procedure
CREATE PROCEDURE test.simpleTest()
BEGIN
SELECT 'Procedure output';
END;
// PDO call
?php
$dbh = new PDO('mysql:host=localhost;dbname=test', 'user', 'password',
array(PDO::ATTR_PERSISTENT = true);
foreach ($dbh-query(CALL simpleTest()) as $row) {
print_r($row);
}
$arr = $dbh-errorInfo();
print_r($arr);
/* Same problem with
$stmt = $dbh-prepare(CALL simpleTest());
$stmt-execute();
foreach ($stmt-fetchAll(PDO::FETCH_ASSOC) as $row) {
print_r($row);
}
$arr = $stmt-errorInfo();
print_r($arr);
*/
?
Expected result:
Array
(
[Procedure output] = Procedure output
[0] = Procedure output
)
Array
(
[0] = 0
)
on odd and even tries/refresh
Actual result:
--
On odd tries (1st, 3rd, etc.):
Array
(
[Procedure output] = Procedure output
[0] = Procedure output
)
Array
(
[0] = 0
)
on even tries (refresh)
Array
(
[0] = HY000
[1] = 2013
[2] = Lost connection to MySQL server during query
)
--
Edit this bug report at http://bugs.php.net/?id=36449edit=1
#36632 [Opn-Csd]: SQLSTATE[] unknown error using MSAccess and write SQL with 0 matching records
ID: 36632
Updated by: [EMAIL PROTECTED]
Reported By: gerwin84 at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: WinXP Pro SP2
PHP Version: 5.1.3RC4-dev
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fix will be in PHP 5.1.4
Previous Comments:
[2006-04-21 14:17:40] gerwin84 at gmail dot com
With the latest windows version,
5.1.3RC4-dev
Build Date Apr 21 2006 12:14:54,
it is still not working.
Exactly the same problem, with no differences.
[2006-04-21 04:10:45] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-06 17:12:55] gerwin84 at gmail dot com
Description:
Using the latest PHP windows package (PHP 5.1.3-dev from 19 feb.) PDO
throws an PDOException with message 'SQLSTATE[]: Unknown error: 0'
when executing an SQL statement (UPDATE or DELETE) where the WHERE
restriction matches zero records in an MSAccess database.
The following ext. are loaded in php.ini:
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Using php-cgi.exe and IIS
Reproduce code:
---
/*
Table 'test' description:
field 'user' text(50) | field 'role' text(50)
*/
$situation = 1; //value can be 1 or 2
$DBPath = d:\\webroot\\database\\pdobug.mdb;
$MSAccessDB = new PDO(odbc:Driver={Microsoft Access Driver
(*.mdb)};Dbq=.$DBPath.;);
$MSAccessDB-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$SQL1 = INSERT INTO test VALUES( 'testuser','testrole');;
$SQL2 = UPDATE test SET role='administrator' WHERE user='testuser' AND
role='testrole';;
$SQL3 = DELETE FROM test WHERE user='testuser';;
$MSAccessDB-exec($SQL1);
switch($situation){
case 1:
$MSAccessDB-exec($SQL2); //ok
$MSAccessDB-exec($SQL2); //error
break;
case 2:
$MSAccessDB-exec($SQL3); //ok
$MSAccessDB-exec($SQL3); //error
break;
}
Expected result:
a blank page as output and changes to the database log:
- Always first a new row added.
- In situation 1: the new row changed.
- In situation 2: the new row deleted.
Actual result:
--
This is the error in in situation 1:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[]: Unknown error: 0 (SQLExecDirect[0] at
ext\pdo_odbc\odbc_driver.c:230)' in D:\webroot\www\test\pdobug.php:20
Stack trace:
#0 D:\webroot\www\test\pdobug.php(20): PDO-exec('UPDATE test SET...')
#1 {main}
thrown in D:\webroot\www\test\pdobug.php on line 20
The error in situation 2 is exacly the same, except line numbers etc.
of course.
--
Edit this bug report at http://bugs.php.net/?id=36632edit=1
#36752 [Opn-Fbk]: pdo_odbc crashes apache
ID: 36752
Updated by: [EMAIL PROTECTED]
Reported By: mauroi at digbang dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Win XP SP2
PHP Version: 5CVS-2006-03-16 (snap)
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Try with the next snapshot dated after this message.
Previous Comments:
[2006-04-21 13:33:16] mauroi at digbang dot com
Yes. It still happens.
phpinfo() reports 5.1.3RC4-dev.
Thank you.
[2006-04-21 04:11:50] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-28 14:26:53] mauroi at digbang dot com
Yes.
The same happens.
Thanks.
[2006-03-28 12:30:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-16 00:14:45] mauroi at digbang dot com
Description:
I'm trying to create a class that provides a layer between the
programmer and the PDO native class.
When running the following code, Apache crashes. Only with the odbc PDO
driver.
Thanks in advance.
Reproduce code:
---
class db
{
protected $_Handle;
function __construct($dsn)
{
$this-_Handle = new PDO($dsn);
}
public function DoSomething()
{
$a = $this-_Handle-prepare('SELECT * FROM valid_table');
echo $undefined_variable; // or any other error
}
}
function strange($errorNumber, $errorMessage)
{
echo $errorMessage;
exit; // if i take this out everything works as expected
}
set_error_handler('strange');
$a = new db('odbc:valid_connection_string');
$b = $a-DoSomething();
Expected result:
The $errorMessage reported by the error handler. And the script
execution terminated.
Actual result:
--
Crash
--
Edit this bug report at http://bugs.php.net/?id=36752edit=1
#37097 [Asn-WFx]: PDO-MSSQL converts bigint to float.
ID: 37097
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
-Status: Assigned
+Status: Wont fix
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5.1.3RC2
Assigned To: wez
New Comment:
That's the stringified format that dblib returns to PDO.
We're not going to fix this; we asked for a string and that's the
string that is handed to us by dblib.
You should also note that dblib on windows is an unsupported legacy
library that has not shipped with SQL server for the last couple of
releases; unless you absolutely MUST use it, you are STRONGLY
recommended to use ODBC to connect to MSSQL.
Previous Comments:
[2006-04-16 20:14:49] [EMAIL PROTECTED]
FYI: You should use PDO ODBC on Windows.
[2006-04-16 07:57:49] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-04-16 07:44:32] stochnagara at hotmail dot com
Description:
PDO MsSql driver returns bigint values as float instead of int.
They are always formated as number.0
Reproduce code:
---
CREATE TABLE demo (
bi bigint not null,
sm int null
);
insert into demo (1,1);
$result = $pdo-query (SELECT * FROM demo)-fetch();
echo bi={$result['bi']};
echo sm={$result['sm']};
Expected result:
bi=1;sm=1;
Actual result:
--
bi=1.0;sm=1;
--
Edit this bug report at http://bugs.php.net/?id=37097edit=1
#37227 [Opn-Bgs]: Error in build version
ID: 37227 Updated by: [EMAIL PROTECTED] Reported By: dsmith at prgrain dot bc dot ca -Status: Open +Status: Bogus Bug Type: PDF related Operating System: Windows PHP Version: 5.1.2 New Comment: Just grab the binaries from: http://pecl4win.php.net/ext.php/php_cpdf.dll http://pecl4win.php.net/ext.php/php_pdf.dll Previous Comments: [2006-04-27 21:02:22] dsmith at prgrain dot bc dot ca Forgot to mention: The version of the PHP_PDF.DLL files and PHP_CPDF.DLL files are the 5.1.2 versions that came with the extra PECL download. They are dated January of 2006. [2006-04-27 20:59:51] dsmith at prgrain dot bc dot ca Description: Use the zipped distribution of PHP 5.1.2 for Wimdows, I have been able to get the core PHP active, but can not get the PDF functions to work. If I enable the extensions PHP_PDF.DLL or PHP_CPDF.dll, I receive an error saying these versions were compiled with a different version, and PHP aborts. I tried installing the PDFLIB Lite package, but the compiled DLL is not recognized as a valid PHP DLL when added to the list of extensions. Is there newer version of these files, or perhaps an alternate installation? Actual result: -- PHP Warning: PHP Startup: SVït$#9658;Wï=#9830;A#9786;#9786;Vhli#9786;#9786;j: Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=1 PHPcompiled with module API=20050922, debug=0, thread-safety=1 These options need to match in Unknown on line 0 br / bWarning/b: PHP Startup: SVït$#9658;Wï=#9830;A#9786;#9786;Vhli#9786;#9786;j: Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=1 PHPcompiled with module API=20050922, debug=0, thread-safety=1 These options need to match in bUnknown/b on line b0/bbr / PHP Warning: PHP Startup: #934;;#9562;: Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=1 PHPcompiled with module API=20050922, debug=0, thread-safety=1 These options need to match in Unknown on line 0 br / bWarning/b: PHP Startup: #934;;#9562;: Unable to initialize module Module compiled with module API=20020429, debug=0, thread-safety=1 PHPcompiled with module API=20050922, debug=0, thread-safety=1 These options need to match in bUnknown/b on line b0/bbr / -- Edit this bug report at http://bugs.php.net/?id=37227edit=1
#37158 [Fbk-Ana]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Analyzed
Bug Type: Streams related
Operating System: n/a
PHP Version: 5CVS-2006-04-21 (CVS)
-Assigned To: pajoye
+Assigned To: wez
New Comment:
A change was made to wrapper resolution that mean that the plain file
wrapper is effectively aliased at alternate locations in memory. This
fundamentally breaks the wrapper implementation macros
(PHP_STREAM_IS(...)) which absolutely rely on the wrapper structures
living at the definitive original address in memory. Other streams
core code also relies on this being the case.
The fix is to change the wrapper hash tables to store pointers to the
wrapper structures instead of having them clone the wrapper
structures.
The reason this problem only triggered when calling
stream_wrapper_register() is that it clones the hash on the first call.
This coupled with a change that allows scripts to override file://
causes regular plain file access (even without file://) to lookup the
cloned plain file wrapper from the cloned hash.
Previous Comments:
[2006-04-22 14:52:11] [EMAIL PROTECTED]
Your example is incomplete, but there was a comment to help to complete
it, next time, please provide a complete script :)
However, I found the problem, please try:
http://pear.php.net/~pierre/check_stream_plainfile_wops.txt
[2006-04-22 04:25:13] [EMAIL PROTECTED]
...or (after opening userspace stream) when 8192 bytes have been read
whichever comes first.
Pierre, I never opened a userspace stream. A user stream was
registered with stream_wrapper_register(), and never used. Read the
example code. The only thing opened was a local file, which is very
much a built-in stream.
This would be equivalent to mysql_query() failing because the code
initialized a pdo object. The two should not affect each other.
[2006-04-21 22:40:09] [EMAIL PROTECTED]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
...or (after opening userspace stream) when 8192 bytes have been read
whichever comes first.
I think it is clear. What do you suggest to make it more clear? Reopen
and change it to documentation bug if you have a better text.
It is not a bug.
[2006-04-21 22:15:15] [EMAIL PROTECTED]
P.S. The documentation still sucks for fread() on the need to read in
chunks.
I ran into this bug because I had an fread() from a local file handle
within a streams handler (pear.php.net/PHP_Archive) that had never been
more than 8192 before.
I would recommend fixing this by adding an E_STRICT warning if a value
larger than 8192 is passed into fread()
[2006-04-21 22:11:09] [EMAIL PROTECTED]
Description:
fread($fp, 2); will read in 2 bytes from a local file, but is a
userspace stream is defined anywhere, it will only read in 8192 bytes,
without any warning or error.
This is actually similar to Bug #30936, but as I say the problem here
is that the presence of a userspace stream handler changes the behavior
of fread() - any indeterminate behavior is bad.
I wonder if the fix from #32810 could be helpful for this problem as
well?
Reproduce code:
---
?php
// paste in the stream code from the example in the manual
// be sure to include stream_wrapper_register
error_reporting(E_ALL | E_STRICT);
$file = dirname(__FILE__) . '/footest.txt';
$x = str_repeat('1', 8192);
$fp = fopen($file, 'w');
for ($i = 0; $i 5; $i++) {
fwrite($fp, $x);
}
fclose($fp);
$fp = fopen($file, 'r');
$outsidecontents = fread($fp, 2);
fclose($fp);
var_dump('size of contents 1 = ' . strlen($outsidecontents));
$outsidecontents = file_get_contents($file);
var_dump('size of contents 2 = ' . strlen($outsidecontents));
?
Expected result:
string(26) size of contents 1 = 2
string(26) size of contents 2 = 40960
Actual result:
--
string(25) size of contents 1 = 8192
string(26) size of contents 2 = 40960
--
Edit this bug report at http://bugs.php.net/?id=37158edit=1
#37158 [Ana]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Analyzed Bug Type: Streams related Operating System: n/a PHP Version: 5CVS-2006-04-21 (CVS) Assigned To: wez New Comment: The following patch corrects the issue: http://y1.php.net/~wez/streams-37158.diff Previous Comments: [2006-04-22 15:36:43] [EMAIL PROTECTED] A change was made to wrapper resolution that mean that the plain file wrapper is effectively aliased at alternate locations in memory. This fundamentally breaks the wrapper implementation macros (PHP_STREAM_IS(...)) which absolutely rely on the wrapper structures living at the definitive original address in memory. Other streams core code also relies on this being the case. The fix is to change the wrapper hash tables to store pointers to the wrapper structures instead of having them clone the wrapper structures. The reason this problem only triggered when calling stream_wrapper_register() is that it clones the hash on the first call. This coupled with a change that allows scripts to override file:// causes regular plain file access (even without file://) to lookup the cloned plain file wrapper from the cloned hash. [2006-04-22 14:52:11] [EMAIL PROTECTED] Your example is incomplete, but there was a comment to help to complete it, next time, please provide a complete script :) However, I found the problem, please try: http://pear.php.net/~pierre/check_stream_plainfile_wops.txt [2006-04-22 04:25:13] [EMAIL PROTECTED] ...or (after opening userspace stream) when 8192 bytes have been read whichever comes first. Pierre, I never opened a userspace stream. A user stream was registered with stream_wrapper_register(), and never used. Read the example code. The only thing opened was a local file, which is very much a built-in stream. This would be equivalent to mysql_query() failing because the code initialized a pdo object. The two should not affect each other. [2006-04-21 22:40:09] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php ...or (after opening userspace stream) when 8192 bytes have been read whichever comes first. I think it is clear. What do you suggest to make it more clear? Reopen and change it to documentation bug if you have a better text. It is not a bug. [2006-04-21 22:15:15] [EMAIL PROTECTED] P.S. The documentation still sucks for fread() on the need to read in chunks. I ran into this bug because I had an fread() from a local file handle within a streams handler (pear.php.net/PHP_Archive) that had never been more than 8192 before. I would recommend fixing this by adding an E_STRICT warning if a value larger than 8192 is passed into fread() The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37158 -- Edit this bug report at http://bugs.php.net/?id=37158edit=1
#37158 [Ana-Csd]: if userspace stream is present, fread() reads in 8192 max, otherwise it works
ID: 37158 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Analyzed +Status: Closed Bug Type: Streams related Operating System: n/a PHP Version: 5CVS-2006-04-21 (CVS) Assigned To: wez New Comment: This bug has been fixed in CVS. Snapshots of the sources are packaged every three hours; this change will be in the next snapshot. You can grab the snapshot at http://snaps.php.net/. Thank you for the report, and for helping us make PHP better. Previous Comments: [2006-04-22 16:02:23] [EMAIL PROTECTED] The following patch corrects the issue: http://y1.php.net/~wez/streams-37158.diff [2006-04-22 15:36:43] [EMAIL PROTECTED] A change was made to wrapper resolution that mean that the plain file wrapper is effectively aliased at alternate locations in memory. This fundamentally breaks the wrapper implementation macros (PHP_STREAM_IS(...)) which absolutely rely on the wrapper structures living at the definitive original address in memory. Other streams core code also relies on this being the case. The fix is to change the wrapper hash tables to store pointers to the wrapper structures instead of having them clone the wrapper structures. The reason this problem only triggered when calling stream_wrapper_register() is that it clones the hash on the first call. This coupled with a change that allows scripts to override file:// causes regular plain file access (even without file://) to lookup the cloned plain file wrapper from the cloned hash. [2006-04-22 14:52:11] [EMAIL PROTECTED] Your example is incomplete, but there was a comment to help to complete it, next time, please provide a complete script :) However, I found the problem, please try: http://pear.php.net/~pierre/check_stream_plainfile_wops.txt [2006-04-22 04:25:13] [EMAIL PROTECTED] ...or (after opening userspace stream) when 8192 bytes have been read whichever comes first. Pierre, I never opened a userspace stream. A user stream was registered with stream_wrapper_register(), and never used. Read the example code. The only thing opened was a local file, which is very much a built-in stream. This would be equivalent to mysql_query() failing because the code initialized a pdo object. The two should not affect each other. [2006-04-21 22:40:09] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php ...or (after opening userspace stream) when 8192 bytes have been read whichever comes first. I think it is clear. What do you suggest to make it more clear? Reopen and change it to documentation bug if you have a better text. It is not a bug. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37158 -- Edit this bug report at http://bugs.php.net/?id=37158edit=1
#35607 [Asn-Fbk]: Crash with Update command
ID: 35607
Updated by: [EMAIL PROTECTED]
Reported By: wseibert at hxcorp dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows 2k
PHP Version: 5CVS-2005-12-08 (snap)
Assigned To: wez
New Comment:
still waiting for the information I requested.
Previous Comments:
[2005-12-09 15:23:21] wseibert at hxcorp dot com
I think i found some more info out.
It seems to have a problem with the aliases of the tables.
This will work:
UPDATE tbl1 SET id=10 WHERE 1=1
This will crash:
UPDATE tbl1 SET tbl1.id=10 WHERE 1=1
Both are valid SQL statements...
I'm not sure if this is caused in one of the ext in PHP (PDO_odbc?) or
where it's crashing from...
Can we get some error catching in PHP5 for this?
[2005-12-09 05:24:37] [EMAIL PROTECTED]
Can you provide a CREATE TABLE statement or a small copy of your actual
.mdb file, so that I can test against the same schema you're using?
[2005-12-08 21:34:46] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-12-08 21:12:16] wseibert at hxcorp dot com
Sorry, I know this is going to be difficult to duplicate as I'm
connecting to a Access DB on my local machine via ODBC. If you have a
Access DB on your system, you just need to set it up in your ODBC
Manager and point to that DSN in the script. Once that is done, try
doing a Update SQL command via PDO::query, Then try it via PDO::exec.
If it works (correctly), it should return the number of rows affected.
It crashes for me on the query, and does nothing on the exec.
[2005-12-08 21:07:57] wseibert at hxcorp dot com
?php
try
{
$dbh = new PDO('odbc:DSN=TEST;driver=Driver do Microsoft Access
(*.mdb)','','');
$results = $dbh-query('UPDATE xd17 SET xd17.CCDate = 20051207,
xd17.CCTime = 1200, xd17.ModifiedDS = 200512071200 WHERE xd17.XTyp17 =
157 AND xd17.X15A = 51921 AND xd157.X105B = 3300');
} catch (PDOException $e) {
print Error!: .$e-getMessage().br/;
die();
}
?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35607
--
Edit this bug report at http://bugs.php.net/?id=35607edit=1
#36632 [Opn-Fbk]: SQLSTATE[] unknown error using MSAccess and write SQL with 0 matching records
ID: 36632
Updated by: [EMAIL PROTECTED]
Reported By: gerwin84 at gmail dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: WinXP Pro SP2
PHP Version: 5.1.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2006-03-06 17:12:55] gerwin84 at gmail dot com
Description:
Using the latest PHP windows package (PHP 5.1.3-dev from 19 feb.) PDO
throws an PDOException with message 'SQLSTATE[]: Unknown error: 0'
when executing an SQL statement (UPDATE or DELETE) where the WHERE
restriction matches zero records in an MSAccess database.
The following ext. are loaded in php.ini:
extension=php_pdo.dll
extension=php_pdo_odbc.dll
Using php-cgi.exe and IIS
Reproduce code:
---
/*
Table 'test' description:
field 'user' text(50) | field 'role' text(50)
*/
$situation = 1; //value can be 1 or 2
$DBPath = d:\\webroot\\database\\pdobug.mdb;
$MSAccessDB = new PDO(odbc:Driver={Microsoft Access Driver
(*.mdb)};Dbq=.$DBPath.;);
$MSAccessDB-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$SQL1 = INSERT INTO test VALUES( 'testuser','testrole');;
$SQL2 = UPDATE test SET role='administrator' WHERE user='testuser' AND
role='testrole';;
$SQL3 = DELETE FROM test WHERE user='testuser';;
$MSAccessDB-exec($SQL1);
switch($situation){
case 1:
$MSAccessDB-exec($SQL2); //ok
$MSAccessDB-exec($SQL2); //error
break;
case 2:
$MSAccessDB-exec($SQL3); //ok
$MSAccessDB-exec($SQL3); //error
break;
}
Expected result:
a blank page as output and changes to the database log:
- Always first a new row added.
- In situation 1: the new row changed.
- In situation 2: the new row deleted.
Actual result:
--
This is the error in in situation 1:
Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[]: Unknown error: 0 (SQLExecDirect[0] at
ext\pdo_odbc\odbc_driver.c:230)' in D:\webroot\www\test\pdobug.php:20
Stack trace:
#0 D:\webroot\www\test\pdobug.php(20): PDO-exec('UPDATE test SET...')
#1 {main}
thrown in D:\webroot\www\test\pdobug.php on line 20
The error in situation 2 is exacly the same, except line numbers etc.
of course.
--
Edit this bug report at http://bugs.php.net/?id=36632edit=1
#36752 [Asn-Fbk]: pdo_odbc crashes apache
ID: 36752
Updated by: [EMAIL PROTECTED]
Reported By: mauroi at digbang dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Win XP SP2
PHP Version: 5CVS-2006-03-16 (snap)
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2006-03-28 14:26:53] mauroi at digbang dot com
Yes.
The same happens.
Thanks.
[2006-03-28 12:30:06] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-03-16 00:14:45] mauroi at digbang dot com
Description:
I'm trying to create a class that provides a layer between the
programmer and the PDO native class.
When running the following code, Apache crashes. Only with the odbc PDO
driver.
Thanks in advance.
Reproduce code:
---
class db
{
protected $_Handle;
function __construct($dsn)
{
$this-_Handle = new PDO($dsn);
}
public function DoSomething()
{
$a = $this-_Handle-prepare('SELECT * FROM valid_table');
echo $undefined_variable; // or any other error
}
}
function strange($errorNumber, $errorMessage)
{
echo $errorMessage;
exit; // if i take this out everything works as expected
}
set_error_handler('strange');
$a = new db('odbc:valid_connection_string');
$b = $a-DoSomething();
Expected result:
The $errorMessage reported by the error handler. And the script
execution terminated.
Actual result:
--
Crash
--
Edit this bug report at http://bugs.php.net/?id=36752edit=1
#35386 [Opn-Sus]: firebird: first row is null
ID: 35386
Updated by: [EMAIL PROTECTED]
-Summary: first row is null
Reported By: slapaf at hotmail dot com
-Status: Open
+Status: Suspended
Bug Type: PDO related
Operating System: winxp sp2
PHP Version: 5CVS-2006-12-02 (snap)
Previous Comments:
[2006-03-27 22:32:47] [EMAIL PROTECTED]
Looking for someone to maintain the firebird driver.
[2006-03-21 16:11:10] salbefe at inf dot upv dot es
I have the same problem in Windows 2003 SP1.
[2006-03-10 09:49:11] astro101 at hotmail dot com
Yes had same problem WinXP SP2 Firebird 1.5.3 and firebird 2 and PHP
5.1.2, PHP5.1.3RC1, PHP5.1.3RC2.
[2006-02-11 17:25:16] thomas at last-it dot de
same problem on linux, php 5.1.2
I tried to debug the problem, but imho the problem is strange.
The reason why the first row is null is as following:
file: ext/pdo/pdo_stmt.c
line: 532
code
case PDO_PARAM_STR:
if (value !(value_len == 0 stmt-dbh-oracle_nulls ==
PDO_NULL_EMPTY_STRING)) {
ZVAL_STRINGL(dest, value, value_len, !caller_frees);
if (caller_frees) {
caller_frees = 0;
}
break;
}
default:
ZVAL_NULL(dest);
/code
With the first returned row from DB the first if clause above evaluates
to false.
so ZVAL_NULL is called. thats the reason for the null values in the
first result set.
Normally should value point to the argument ptr of the
firebird_stmt_get_col function (in firebird_statement.c).
gdp says that ptr is filled with the data out of DB properly.
So why is value not the same as ptr and why is this only in the
first result set??
greetz Thomas
[2006-02-08 18:49:28] turyak at gmail dot com
yep, experiencing same problem..
php 5.1.2, firebird 1.5.2
is there solution already?
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35386
--
Edit this bug report at http://bugs.php.net/?id=35386edit=1
#37124 [Asn-Fbk]: PostgreSQL Query Returns Resource id for Field Value
ID: 37124 Updated by: [EMAIL PROTECTED] Reported By: ahaig at penguinmilitia dot net -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Mac OS X 10.4.6 PHP Version: 5.1.2 Assigned To: wez New Comment: Sounds like a LOB type... tried using the streams functions to read it? (the resource is a stream). Previous Comments: [2006-04-19 09:58:31] [EMAIL PROTECTED] Assigned to the maintainer. [2006-04-18 18:10:56] ahaig at penguinmilitia dot net pg_trigger.tgargs is a built in column in template1... Looks like it's a bytea type. (\d pg_trigger) [2006-04-18 18:07:37] [EMAIL PROTECTED] What is the postgres data type you return here? [2006-04-18 18:04:15] ahaig at penguinmilitia dot net I guess I didn't include ?php ? but I thought I included a full script. You will need to fill in $dsn $user and $password and $table as appropriate. $dsn should refer to a PostgreSQL DB, $table to a table with at least 1 foreign key. Script: ?php $database = new PDO( $dsn, $user, $password ); $statement = $database-prepare(SELECT t.tgargs as args FROM pg_trigger t,pg_class c,pg_proc p WHERE t.tgenabled AND t.tgrelid = c.oid AND t.tgfoid = p.oid AND p.proname = 'RI_FKey_check_ins' AND c.relname =:tablename ORDER BY t.tgrelid); $table = 'name of table in database with at least 1 foreign key'; $statement-bindParam( ':tablename', $table ); $statement-execute(); print_r($statement-fetchAll()); die(Here's my error!); ? [2006-04-18 17:57:30] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/37124 -- Edit this bug report at http://bugs.php.net/?id=37124edit=1
#37097 [Asn]: PDO-MSSQL converts bigint to float.
ID: 37097
Updated by: [EMAIL PROTECTED]
Reported By: stochnagara at hotmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: windows xp
PHP Version: 5.1.3RC2
Assigned To: wez
New Comment:
FYI: You should use PDO ODBC on Windows.
Previous Comments:
[2006-04-16 07:57:49] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-04-16 07:44:32] stochnagara at hotmail dot com
Description:
PDO MsSql driver returns bigint values as float instead of int.
They are always formated as number.0
Reproduce code:
---
CREATE TABLE demo (
bi bigint not null,
sm int null
);
insert into demo (1,1);
$result = $pdo-query (SELECT * FROM demo)-fetch();
echo bi={$result['bi']};
echo sm={$result['sm']};
Expected result:
bi=1;sm=1;
Actual result:
--
bi=1.0;sm=1;
--
Edit this bug report at http://bugs.php.net/?id=37097edit=1
#36402 [Opn-Fbk]: PDO_MYSQL prepared statements cause Out of memory or data corruption
ID: 36402 Updated by: [EMAIL PROTECTED] Reported By: joh at deworks dot net -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Linux PHP Version: 5CVS-2006-02-15 (snap) New Comment: Please try configuring PHP using: --disable-zend-memory-manager and then run the PHP script under valgrind from the CLI: % ./configure ... --disable-zend-memory-manager --enable-cli % make % valgrind --tool=memcheck ./sapi/cli/php myscript.php You can find valgrind at http://valgrind.org/. This should highlight memory corruption issues. Previous Comments: [2006-04-09 14:10:44] joh at deworks dot net Just tested with the latest snapshot (php5.1-200604091030), and the problem still persists. [2006-04-09 07:52:21] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-04-06 13:48:24] czw at home dot se Got the same error: PHP 5.1.2, MySQL 4.1.14. This error is NOT present in PHP 5.1.1. I would suggest downgrading. [2006-02-23 00:07:06] joh at deworks dot net So was anything done about this, or was it forgotten? Status report? [2006-02-15 22:20:50] joh at deworks dot net I've tried the latest snapshot (I tried it before I reported this bug), and the problem still persists. Sorry. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36402 -- Edit this bug report at http://bugs.php.net/?id=36402edit=1
#35910 [Opn-Ver]: Crash possibly related to Class, PDO, or combination. Seems like memory error
ID: 35910
Updated by: [EMAIL PROTECTED]
Reported By: Ryan dot Melena at gmail dot com
-Status: Open
+Status: Verified
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1CVS-2006-01-05 (snap)
Assigned To: wez
New Comment:
I can reproduce this on linux.
It appears to be less of a problem if you avoid binding to variables
that are members of an object.
I haven't been able to pinpoint exactly what the cause is, as it
appears to change subtly as the script is modified.
I remember that once-upon-a-time, referencing $this inside a
constructor would lead to problems, perhaps this is a manifestation of
that issue.
Previous Comments:
[2006-04-09 14:53:55] Ryan dot Melena at gmail dot com
?php
/* SQL
CREATE TABLE IF NOT EXISTS `section` (
`id` int(10) unsigned NOT NULL auto_increment,
`parentSectionID` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=8 ;
INSERT INTO `section` VALUES (1, 1);
INSERT INTO `section` VALUES (2, 1);
INSERT INTO `section` VALUES (3, 2);
INSERT INTO `section` VALUES (4, 1);
INSERT INTO `section` VALUES (5, 5);
INSERT INTO `section` VALUES (6, 6);
INSERT INTO `section` VALUES (7, 6);
*/
?
?php
global $db_host, $db_name, $db_username, $db_password;
$db_host = 'localhost';
$db_name = 'test';
$db_username = 'root';
$db_password = 'superw00t';
class section
{
private $id = null;
private $parentSectionID = null;
private $childSections = array();
private $status = array('consistentWithDb' = false,
'childSectionsLoaded' = false);
function __construct($id)
{
$db = resourceHelper::getDbConn();
// Validate $id and load section data
if(!is_int($id))
{
throw new Exception('Invalid argument for
section::loadFromDb(), $id must be an int. Value sent was [' . $id .
'] of type [' . gettype($id) . '].');
}
$this-id = $id;
$query ='SELECT parentSectionID FROM section WHERE id =
:id';
$stmt = $db-prepare($query);
$stmt-bindValue(':id', $this-id , PDO::PARAM_INT);
$stmt-execute();
$stmt-bindColumn('parentSectionID',$this-parentSectionID,
PDO::PARAM_INT);
$stmt-fetch(PDO::FETCH_BOUND);
$stmt = null;
$db = null;
}
function __get($varName)
{
switch($varName)
{
case 'id':
return (int)$this-id;
case 'childSections':
if(!$this-status['childSectionsLoaded'])
{
$this-loadChildSections();
}
return $this-childSections;
default:
throw new Exception('Variable [' . $varName . '] is not
a public member of section.');
break;
}
}
private function loadChildSections()
{
$sectionID = null;
$db = resourceHelper::getDbConn();
$query = 'SELECT id FROM section WHERE parentSectionID = :id
AND parentSectionID != id';
$stmt = $db-prepare($query);
$stmt-bindValue(':id',$this-id,PDO::PARAM_INT);
$stmt-execute();
$stmt-bindColumn('id',$sectionID,PDO::PARAM_INT);
while($stmt-fetch(PDO::FETCH_BOUND))
{
$this-childSections[] = new section($sectionID);
}
$this-status['childSectionsLoaded'] = true;
}
}
class resourceHelper
{
public static function getDbConn()
{
global $db_host, $db_name, $db_username, $db_password;
// Create and Validate database connection
try
{
$db = new PDO('mysql:host=' . $db_host . ';dbname=' .
$db_name, $db_username, $db_password);
$db-setAttribute(PDO::ATTR_ERRMODE,
PDO::ERRMODE_EXCEPTION);
}
catch(Exception $e)
{
throw new Exception('Unable to connect to database [' .
$config['db']['name'] . '] using configuration file values.' .
$e-getMessage());
}
return $db;
}
}
$db = resourceHelper::getDbConn();
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$sectionID = null;
$query = 'SELECT id FROM section WHERE id = parentSectionID';
$stmt = $db-prepare($query);
$stmt-execute();
$stmt-bindColumn('id',$sectionID,PDO::PARAM_INT);
while($stmt-fetch(PDO::FETCH_BOUND))
{
$section = new section($sectionID);
buildSectionRow($section);
}
$stmt = null;
$db = null;
function buildSectionRow(section $section, $indent = 0)
{
echo $section-id . 'br /';
$indent++;
/*
To reproduce error, comment out $test definition then
replace $test in foreach loop
#35793 [Asn-Fbk]: General error: 2050
ID: 35793
Updated by: [EMAIL PROTECTED]
Reported By: deadman_great at mail dot ru
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: RH Fedora Core 2
PHP Version: 5CVS-2005-12-25 (snap)
Assigned To: Wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Try the next snapshot dated after this message.
Previous Comments:
[2006-03-23 00:25:26] qlogix at gmail dot com
I can confirm the statement on Centos 4.1, PHP 5.1.2, Mysql 4.1.16
You cannot use the same variable for a PDOStatement object twice. As
others have pointed out it works when you set this variable to null in
between.
?php
$db = new PDO(SQL_DSN,SQL_USER,SQL_PASSWORD);
$db-setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION);
$result = $db-query('SELECT COUNT(*) FROM Locations');
echo $result.br;
$row = $result-fetchAll(PDO::FETCH_ASSOC);
/* Comment the next line out and script returns an error */
//$result = null;
$result = $db-query('SELECT COUNT(*) FROM Accounts');
echo $result.br;
$row = $result-fetch(PDO::FETCH_ASSOC); /* This line causes the error
*/
?
With line $result = null; commented out:
Object id #2
Object id #3
PDOException Object
(
[message:protected] = SQLSTATE[HY000]: General error: 2050
With line $result = null; not commented out:
Object id #2
Object id #2
No error message (script works)
[2006-03-21 18:37:15] email at steffenweber dot net
I can confirm that this error does not occur on Windows XP + PHP 5.1.2
+ MySQL 5.0.18. It does happen for me on Gentoo Linux + PHP 5.1.2 +
MySQL 4.1.16.
You cannot use the same variable for a PDOStatement object twice. As
others have pointed out it works when you set this variable to null in
between.
[2006-03-18 22:09:27] gg15 at gmx dot net
$result = $db-query('SELECT COUNT(*) FROM XYZ');
$row = $result-fetch(PDO::FETCH_ASSOC);
$result-closeCursor();
$result = $db-query('SELECT * FROM XYZ');
$row = $result-fetch(PDO::FETCH_ASSOC); // this one throws the error
an $result = null; between the statements fixes the issue, so I think
this is a problem of php...
[2006-03-11 10:42:51] peres dot yzqk8 at mailnull dot com
I'd got same problem with this piece of code:
$s = $db-query(SELECT * FROM test ORDER BY poledrugie;);
var_dump($s-fetchAll());
$s = $db-query(SELECT * FROM test ORDER BY poletrzecie;);
var_dump($s-fetchAll());
Changed it to:
$s = $db-query(SELECT * FROM test ORDER BY poledrugie;);
var_dump($s-fetchAll());
$st = $db-query(SELECT * FROM test ORDER BY poletrzecie;);
var_dump($st-fetchAll());
So I think it's wrong use of PHP objects...
[2006-02-14 16:06:00] m at tacker dot org
I can reproduce this bug on two machines (athlon-xp and pentium3) with
PHP 5.1.1-gentoo (cli) (built: Feb 10 2006 18:06:50)
Zend Engine v2.1.0
This is the test case:
?php
/**
* Test case for bug #35793
* @see http://bugs.php.net/bug.php?id=35793
*
* @author Markus Tacker [EMAIL PROTECTED]
* @version $Id: pdo-proxy-bug.php 760 2006-02-14 14:59:19Z mtacker
$
*/
// If you set this to true I will reconnect before each select
// at line 56
// = no crash
$reconnect_before_select = false;
error_reporting(E_ALL|E_STRICT);
ini_set('display_errors', 1);
$dsn = array(
'dbtype' = 'mysql',
'host' = 'localhost',
'database' = 'test',
'username' = 'test',
'password' = '',
);
// $DB = new Database;
$DB = new PDO($dsn['dbtype'] . ':host=' . $dsn['host'] . ';dbname='
. $dsn['database'], $dsn['username'], $dsn['password']);
$table = uniqid();
// Create a test table
$sql = 'CREATE TABLE `' . $table . '` ('
. varname varchar(64) NOT NULL default '',
. varvalue tinytext NOT NULL default '',
. 'PRIMARY KEY (varname)'
. ') ENGINE=InnoDB DEFAULT CHARSET=utf8';
$result = $DB-exec($sql);
if ($result === false and $result-errorCode() != PDO::ERR_NONE) {
exit('Query failed: ' . $sql . \n);
}
echo 'OK: ' . $sql . \n;
// Insert into test table
$sql = 'INSERT INTO `' . $table . '`'
. ' (varname, varvalue)'
. ' VALUES (' . $DB-quote('uniqid') . ', ' . $DB-quote($table) .
')';
$result = $DB-exec($sql);
if ($result === false and $result-errorCode() != PDO::ERR_NONE) {
exit('Query failed: ' . $sql . \n);
}
echo 'OK: ' . $sql . \n;
// Select from table
for ($i = 0; $i 10; $i++) {
if ($reconnect_before_select
#35830 [Asn-Fbk]: Type mismatch with bind variables
ID: 35830 Updated by: [EMAIL PROTECTED] Reported By: nate-php at seekio dot com -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Debian 3.1 Sarge PHP Version: 5CVS-2005-12-29 (snap) Assigned To: wez New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2005-12-29 10:08:59] [EMAIL PROTECTED] Assigned to the PDO maintainer. [2005-12-29 01:32:54] nate-php at seekio dot com Same thing: Exception at line 19 of file testdb.php: SQLSTATE[22005]: Error in assignment: -9 [IBM][CLI Driver] CLI0112E Error in assignment. SQLSTATE=22005 (SQLExecute[-9] at /usr/local/src/php5.1-200512282330/ext/pdo_odbc/odbc_stmt.c:133) [2005-12-29 01:20:26] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2005-12-29 01:02:59] nate-php at seekio dot com Yes, I'm quite sure. I can install 5.1.0 and it works fine, touch nothing but the version and it stops working. Here is the configure line for php, which I forgot to give earlier: ./configure --with-apache=../apache_1.3.34 --with-mysql --with-pdo-mysql --with-gd --with-zlib --with-gettext --with-pdo-odbc=ibm-db2,/home/db2inst1/sqllib The php.ini is just the php.ini-recommended from the tarball with no changes, and nothing in the apache conf overriding anything other than the include path. Thanks, Nate [2005-12-28 21:06:41] [EMAIL PROTECTED] The same code that worked fine in 5.1.0 Are you sure? The only difference between 5.1.0 and 5.1.1 is that 5.1.1 doesn't have Date class, which obviously doesn't affect PDO in any way. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35830 -- Edit this bug report at http://bugs.php.net/?id=35830edit=1
#35910 [Asn-Fbk]: Crash possibly related to Class, PDO, or combination. Seems like memory error
ID: 35910 Updated by: [EMAIL PROTECTED] Reported By: Ryan dot Melena at gmail dot com -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Windows XP PHP Version: 5.1CVS-2006-01-05 (snap) Assigned To: wez New Comment: Please paste the script into the bug report. I can't reach the URL you posted. Previous Comments: [2006-01-05 22:24:45] [EMAIL PROTECTED] Yes, this is right, but it doesn't add any understanding. Assigned to the PDO maintainer. [2006-01-05 22:18:47] Ryan dot Melena at gmail dot com Hope this is right... From Visual Studio: php5ts.dll!_efree(void * ptr=0x00ed982c) Line 303 + 0x1a bytes C php5ts.dll!zend_hash_del_key_or_index(_hashtable * ht=0x00eb4fe0, char * arKey=0x00ed9840, unsigned int nKeyLength=15, unsigned long h=0, int flag=0) Line 490 + 0x6 bytes C php5ts.dll!zend_hash_reverse_apply(_hashtable * ht=0x00eb4fe0, int (void *, void * * *)* apply_func=0x10096c10, void * * * tsrm_ls=0x003225b8) Line 738 + 0xf bytes C php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x003225b8) Line 268 C php5ts.dll!zend_deactivate(void * * * tsrm_ls=0x003225b8) Line 848 C php5ts.dll!php_request_shutdown(void * dummy=0x) Line 1287C php.exe!main(int argc=2, char * * argv=0x00323f90) Line 1231 C php.exe!_mainCRTStartup() + 0xe3 bytes kernel32.dll!7c816d4f() [Frames below may be incorrect and/or missing, no symbols loaded for kernel32.dll] kernel32.dll!7c8399f3() [2006-01-05 22:07:15] [EMAIL PROTECTED] Yeah, that's what I think is causing it. Could you try to install MySQL 4.x and see if you can reproduce the problem? Also read this: http://bugs.php.net/bugs-generating-backtrace-win32.php http://bugs.php.net/bugs-generating-backtrace.php [2006-01-05 22:01:37] Ryan dot Melena at gmail dot com MySQL version is: 5.0.15 on XP. 5.0.16 on Linux. [2006-01-05 22:00:46] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php for *NIX and http://bugs.php.net/bugs-generating-backtrace-win32.php for Win32 Once you have generated a backtrace, please submit it to this bug report and change the status back to Open. Thank you for helping us make PHP better. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35910 -- Edit this bug report at http://bugs.php.net/?id=35910edit=1
#35935 [Asn-Bgs]: MySQL stored procedure doesn't return value when using bindParam()
ID: 35935
Updated by: [EMAIL PROTECTED]
Reported By: victoria at balic dot net
-Status: Assigned
+Status: Bogus
Bug Type: PDO related
Operating System: RHEL4-64/CentOS 4.2-64
PHP Version: 5.1.1
Assigned To: wez
New Comment:
MySQL doesn't supporting binding output parameters via its C API. You
must use SQL level variables:
$stmt = $db-prepare(CALL sp_returns_string(@a));
$stmt-execute();
print_r($db-query(SELECT @a)-fetchAll());
Previous Comments:
[2006-03-09 19:55:22] keyvez at hotmail dot com
I am experiencing the same issue on Windows and MSSQL.
Stored Procedure Create Code:
**
CREATE PROCEDURE [dbo].[p_sel_all_termlength]
@err INT = 0 OUTPUT AS
SELECT * FROM termlength
SET @err = 2627
**
PHP Code:
**
$Link = new PDO('mssql:host=sqlserver;dbname=database', 'username',
'password');
$ErrorCode = 0;
$Stmt = $Link-prepare('p_sel_all_termlength ?');
$Stmt-bindParam(1,$ErrorCode,PDO::PARAM_INT,4);
$Stmt-execute();
echo Error = . $ErrorCode . \n;
while ($Row = $Stmt-fetch(PDO::FETCH_OBJ)) {
echo $Row-description . \n;
}
echo Error = . $ErrorCode . \n;
**
PHP Output:
**
Error = 0
9 Weeks
Semester
One Year
Trimester
Error = 0
**
[2006-01-09 20:34:14] victoria at balic dot net
I just used the latest snapshot as instructed (5.1.2RC3-dev 20060109)
and I get the same behaviour as reported above -- ie. the PDO call
returns empty value when using bindParam().
[2006-01-09 10:19:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-01-09 00:26:08] victoria at balic dot net
Description:
I created a trivial stored procedure in MySQL (v5.0.17) that simply
returns an integer constant. If I call the procedure using a PDO
statement and binding a return value $stmt-bindParam(), I get nothing.
On the other hand, if I issue two SQL queries to implicitly obtain the
result, things are ok (see below). So something is broken with the way
PDO handles bindParam.
I am using the latest stable release of PHP (5.1.1), MySQL 5.0.17 and
mod_php for Apache 2.2
Reproduce code:
---
?php
$DB = new PDO(...);
if($DB != NULL) {
$stmt = $DB-prepare( CALL test_pdo(?));
$stmt-bindParam(1, $return_value, PDO::PARAM_INT, 10);
$stmt-execute();
print Procedure returned: $return_value \n;
//try instead plain SQL call
$DB-query(CALL test_pdo(@nn));
$rows = $DB-query(SELECT @nn)-fetchAll();
print SELECT returned: \n;
print_r($rows);
}
?
And here's actual MySQL Stored procedure:
CREATE PROCEDURE test_pdo
(OUT Pout INTEGER)
BEGIN
SET Pout := 1912;
END
Expected result:
$return_value should have been set to 1912 and instead it's empty.
The stored procedure is working ok as the second call (in which i
implicitly obtain the output by making two SQL queries) returns the
correct value (see below).
Actual result:
--
Procedure returned:
SELECT returned:
Array ( [0] = Array ( [EMAIL PROTECTED] = 1912 [0] = 1912 ) )
--
Edit this bug report at http://bugs.php.net/?id=35935edit=1
#36128 [Asn-Opn]: Interbase PDO
ID: 36128
Updated by: [EMAIL PROTECTED]
Reported By: michael at bluemoon dot com
-Status: Assigned
+Status: Open
Bug Type: PDO related
Operating System: Linux/Windows
PHP Version: 5.1.2
Assigned To: wez
New Comment:
Looking for a firebird maintainer.
Previous Comments:
[2006-01-25 17:08:02] michael at bluemoon dot com
To amend my earlier problem description, it appears that I CAN issue
the SELECT query shown in my previous example successfully. However,
it appears that I cannot retrieve values from TIMESTAMP-type columns.
If I substitute SELECT MY_TIMESTAMP_FIELD FROM MY_TABLE for the query
in my original code, it will execute without throwing an exception, but
the value returned is empty (null). The result I am expecting is an
integer (Unix timestamp) value.
I don't know if this constitutes a 'bug' or if I am simply not going
about this the right way. I have tried many of the various
permutations for fetching results as shown in the PDO documentation,
but nothing seems to work.
Is there a way to fetch TIMESTAMP values using the Firebird/Interbase
PDO driver?
[2006-01-23 10:51:33] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-23 02:21:25] michael at bluemoon dot com
Description:
Exception thrown when issuing SELECT query using PDO driver
for Firebird/Interbase. Database Server runs Interbase 7.5.x
(Linux).
Problem occurs with PHP 5.1.2 running in both Linux/Apache 2
and Windows 2000/IIS environments.
Tried running PHP alternately with Interbase 6 and 7.5 Run-
time Client Libraries on each platform; same problem.
Native PHP Firebird/Interbase functions (e.g., ibase_connect
(), etc.) functions work fine in same environments used to
test PDO functions.
Confirmed DSN string used in my PDO connection function is
correct by testing PDO::ATTR_CONNECTION_STATUS attribute;
value returned is 1.
Reproduce code:
---
try {
$dbh = new PDO($dsn, $user, $password, array(
PDO::ATTR_PERSISTENT = true
));
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $dbh-prepare(SELECT Count(*) FROM MY_TABLE);
$stmt-execute();
$row = $stmt-fetch(PDO::FETCH_NUM);
$stmt = null;
echo $row[0];
}
catch (PDOException $e) {
die $e-getMessage();
}
Expected result:
Should output integer value result from SELECT query to screen
Actual result:
--
Outputs the following error:
SQLSTATE[HY000]: General error: -804 Dynamic SQL Error SQL
error code = -804 Incorrect values within SQLDA structure
--
Edit this bug report at http://bugs.php.net/?id=36128edit=1
#36143 [Asn-Fbk]: bindParam on UPDATE error
ID: 36143 Updated by: [EMAIL PROTECTED] Reported By: lvm99 at mail dot ru -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: Windows PHP Version: 5.1.2 Assigned To: wez New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-01-25 13:34:00] [EMAIL PROTECTED] It very actual to fix this error quick because Get the sources and fix it yourself if you want it quick. Otherwise you have to wait for the maintainer to take a look at it and (maybe) fix it. Please don't change status of the report, it's assigned to the maintainer. [2006-01-25 13:26:03] lvm99 at mail dot ru It very actual to fix this error quick because in ODBC function quote() is not implemented so We cant use simple sql without parameters :-( I cant use MSSQL under PDO because it works with OEM charset and dont implement CHARSET opt handling under Windows :-( So some Russian characters in CP1251 encoding (which actually used in Windows filenames, texts, etc.) are absent in cp866 (russian OEM encoding). Should I report about MSSQL BUG separately (In manual they recomend dont use it on windows as useing absolete DBLIB direct access to MSSQL Server)? [2006-01-25 13:18:42] [EMAIL PROTECTED] Assigned to the maintainer. [2006-01-25 13:04:10] lvm99 at mail dot ru Here You can fild working test base and script http://converters.ru/PHP_TEST_PDO.ZIP On my PC script inserts all fields to :id and updates all fields to :id [2006-01-24 14:53:04] [EMAIL PROTECTED] Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with ?php and ends with ?, is max. 10-20 lines long and does not require any external resources such as databases, etc. If possible, make the script source available online and provide an URL to it here. Try to avoid embedding huge scripts into the report. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36143 -- Edit this bug report at http://bugs.php.net/?id=36143edit=1
#36318 [Asn-Fbk]: Core Dump when using bindParam with PDO_OCI
ID: 36318
Updated by: [EMAIL PROTECTED]
Reported By: bernhard dot hari at multisports dot ch
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: RedHat Linux Enterprise 4 Upd 2
PHP Version: 5.1.2
Assigned To: wez
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2006-02-17 10:50:55] developit at mail dot ru
Multiple bindValue()'s also crash.. Recently bound value seems to get
propogated to all variables of the statement.
$query =
'INSERT INTO SMTH(FIELDA, FIELDB, FIELDC)
VALUES (?, ?, ?)';
$stmt = $DBH-prepare($query);
$stmt-bindValue(1, 'a');
$stmt-bindValue(2, 'b');
$stmt-bindValue(3, 'c');
$stmt-execute();
$stmt = null;
Here ['c','c','c'] row is inserted instead of ['a','b','c'].. The same
happens when I use named placeholders. And the same again when I pass
values as execute() array parameter.
Very similar to bug #35671.
PHP version: 5.1.2
Oracle version: 10.1
OS: Linux
[2006-02-07 16:37:32] bernhard dot hari at multisports dot ch
GNU DDD 3.3.9 (i386-redhat-linux-gnu), by Dorothea Lütkehaus and
Andreas Zeller.
Copyright © 1995-1999 Technische Universität Braunschweig, Germany.
Copyright © 1999-2001 Universität Passau, Germany.
Copyright © 2001 Universität des Saarlandes, Germany.
Copyright © 2001-2004 Free Software Foundation, Inc.
(gdb) file /opt/php5.1-latest/bin/php
Using host libthread_db library /lib/tls/libthread_db.so.1.
(gdb) run Test.php
[Thread debugging using libthread_db enabled]
[New Thread -1208076608 (LWP 17847)]
Detaching after fork from child process 17850.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1208076608 (LWP 17847)]
oci_bind_input_cb (ctx=0xbfffc9c0, bindp=0x865d474, iter=0, index=0,
bufpp=0x865d4f4, alenp=0x865d56c, piecep=0xbfff7a28 \a,
indpp=0xbfff7a28) at
/home/harb/download/php/php5.1-200602071130/ext/pdo_oci/oci_statement.c:177
/data/download/php/php5.1-200602071130/ext/pdo_oci/oci_statement.c:177:5163:beg:0x814a441
static sb4 oci_bind_input_cb(dvoid *ctx, OCIBind *bindp, ub4 iter, ub4
index, dvoid **bufpp, ub4 *alenp, ub1 *piecep, dvoid **indpp) /* {{{
*/
{
struct pdo_bound_param_data *param = (struct
pdo_bound_param_data*)ctx;
pdo_oci_bound_param *P =
(pdo_oci_bound_param*)param-driver_data;
TSRMLS_FETCH();
if (!param || !param-parameter) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, param is
NULL in oci_bind_input_cb; this should not happen);
return OCI_ERROR;
}
*indpp = P-indicator;
==fail if (P-thing) {
*bufpp = P-thing;
*alenp = sizeof(void*);
} else if (ZVAL_IS_NULL(param-parameter)) {
/* insert a NULL value into the column */
P-indicator = -1; /* NULL */
*bufpp = 0;
*alenp = -1;
} else if (!P-thing) {
/* regular string bind */
convert_to_string(param-parameter);
*bufpp = Z_STRVAL_P(param-parameter);
*alenp = Z_STRLEN_P(param-parameter);
}
*piecep = OCI_ONE_PIECE;
return OCI_CONTINUE;
} /* }}} */
backtrace:
#0 oci_bind_input_cb (ctx=0xbfffc9c0, bindp=0x865d474, iter=0,
index=0, bufpp=0x865d4f4, alenp=0x865d56c, piecep=0xbfff7a28 \a,
indpp=0xbfff7a28) at
/home/harb/download/php/php5.1-200602071130/ext/pdo_oci/oci_statement.c:177
#1 0x012fa126 in ttcGetSendInfo () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#2 0x012faf44 in ttcacs () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#3 0x01288d4a in ttcdrv () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#4 0x0117eec1 in nioqwa () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#5 0x00fe32d7 in upirtrc () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#6 0x00f58f76 in kpurcsc () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#7 0x00f0e5bb in kpuexecv8 () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#8 0x00f1094a in kpuexec () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#9 0x00fe7e42 in OCIStmtExecute () from
/opt/oracle/10gr2/lib/libclntsh.so.10.1
#10 0x0814a268 in oci_stmt_execute (stmt=0x1) at
/home/harb/download/php/php5.1-200602071130/ext/pdo_oci/oci_statement.c:140
#11 0x08142895 in zif_PDOStatement_execute (ht=0,
return_value=0x8674e14, return_value_ptr=0x0, this_ptr=0x8655a84,
return_value_used=1) at
/home/harb/download/php/php5.1-200602071130/ext/pdo/pdo_stmt.c:424
#12 0x082a5f49 in zend_do_fcall_common_helper_SPEC
(execute_data=0xbfffcd70) at
/home/harb/download/php/php5.1-200602071130/Zend/zend_vm_execute.h:192
#13 0x082a5901 in execute (op_array=0x86509fc) at
/home/harb/download
#36402 [Opn-Fbk]: PDO_MYSQL prepared statements cause Out of memory or data corruption
ID: 36402 Updated by: [EMAIL PROTECTED] Reported By: joh at deworks dot net -Status: Open +Status: Feedback Bug Type: PDO related Operating System: Linux PHP Version: 5CVS-2006-02-15 (snap) New Comment: Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip Previous Comments: [2006-04-06 13:48:24] czw at home dot se Got the same error: PHP 5.1.2, MySQL 4.1.14. This error is NOT present in PHP 5.1.1. I would suggest downgrading. [2006-02-23 00:07:06] joh at deworks dot net So was anything done about this, or was it forgotten? Status report? [2006-02-15 22:20:50] joh at deworks dot net I've tried the latest snapshot (I tried it before I reported this bug), and the problem still persists. Sorry. [2006-02-15 16:45:41] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip [2006-02-15 15:04:05] joh at deworks dot net Forgot to mention that I'm running MySQL 4.1.12 The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36402 -- Edit this bug report at http://bugs.php.net/?id=36402edit=1
#36449 [Opn-Fbk]: Procedure call + PDO::ATTR_PERSISTENT = true
ID: 36449
Updated by: [EMAIL PROTECTED]
Reported By: brice dot joly at free dot fr
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
The next snapshot dated after this message likely fixes this.
Previous Comments:
[2006-02-18 21:55:19] brice dot joly at free dot fr
Description:
When calling a procedure from PDO with PDO::ATTR_PERSISTENT = true, I
have a very strange behaviour when refreshing the page: on odd tries it
works as expected, on even ones PDO makes the call, then loses
connection while retrieving the result. Direct and prepared call both
produce the same behaviour. Note that the call is actually ran by MySQL
in both cases (appears in the query log).
When switching PDO::ATTR_PERSISTENT to false all works as expected.
Running the test with PHP CLI works fine. I run PHP (tested with
snapshot of 17 Feb 2006, 5.1.3-dev, had the same problem with 5.1.2) as
a module, Apache 2.0.52, MySQL 5.0.18.
Reproduce code:
---
// MySQL Procedure
CREATE PROCEDURE test.simpleTest()
BEGIN
SELECT 'Procedure output';
END;
// PDO call
?php
$dbh = new PDO('mysql:host=localhost;dbname=test', 'user', 'password',
array(PDO::ATTR_PERSISTENT = true);
foreach ($dbh-query(CALL simpleTest()) as $row) {
print_r($row);
}
$arr = $dbh-errorInfo();
print_r($arr);
/* Same problem with
$stmt = $dbh-prepare(CALL simpleTest());
$stmt-execute();
foreach ($stmt-fetchAll(PDO::FETCH_ASSOC) as $row) {
print_r($row);
}
$arr = $stmt-errorInfo();
print_r($arr);
*/
?
Expected result:
Array
(
[Procedure output] = Procedure output
[0] = Procedure output
)
Array
(
[0] = 0
)
on odd and even tries/refresh
Actual result:
--
On odd tries (1st, 3rd, etc.):
Array
(
[Procedure output] = Procedure output
[0] = Procedure output
)
Array
(
[0] = 0
)
on even tries (refresh)
Array
(
[0] = HY000
[1] = 2013
[2] = Lost connection to MySQL server during query
)
--
Edit this bug report at http://bugs.php.net/?id=36449edit=1
#36561 [Opn-Fbk]: PDO_ODBC/MSSQL does not work with bound params in subquery
ID: 36561
Updated by: [EMAIL PROTECTED]
Reported By: travis at raybold dot com
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP
PHP Version: 5.1.2
New Comment:
Try using:
$oStatement-bindParam(':TestID', $iTestID);
instead of:
$oStatement-bindParam(':TestID', $iTestID,PDO::PARAM_INT );
The latter is implicitly binding for output, which might be part of
your problem.
Previous Comments:
[2006-02-28 17:10:09] travis at raybold dot com
Description:
Connecting to a MSSQL database through PDO_ODBC, I prepare a statement
with a bound parameter inside of a subquery, and get a 42000 Syntax
Error when I execute it.
The error indicates that it is trying to compare text. ntext or image
data, but the table consists solely of one integer field. Moving the
bound parameter outside of the subquery makes it work.
I am using PHP 5.1.2, MSSQL 2000, Windows XP, IIS6.
Configure Line: cscript /nologo configure.js --enable-snapshot-build
--with-gd=shared
Reproduce code:
---
MSSQL:
CREATE TABLE zTest_TBL (
TestID int NULL
)
INSERT INTO zTest_TBL (TestID) Values (1)
PHP:
?
$iTestID=1;
$oConnection = new PDO($sDSN, $GLOBALS[sDatabase_Username],
$GLOBALS[sDatabase_Password]);
$oStatement = $oConnection-prepare('SELECT TestID FROM zTest_TBL WHERE
TestID IN (SELECT TestID FROM zTest_TBL WHERE TestID = :TestID)');
//$oStatement = $oConnection-prepare('SELECT TestID FROM zTest_TBL
WHERE TestID = :TestID AND TestID IN (SELECT TestID FROM zTest_TBL
)');
$oStatement-bindParam(':TestID', $iTestID,PDO::PARAM_INT );
$oStatement-execute() or print_r($oStatement-errorInfo());
foreach($oStatement as $aRow) {
print_r($aRow);
}
?
Expected result:
Array ( [TestID] = 1 [0] = 1 )
Actual result:
--
Array ( [0] = 42000 [1] = 306 [2] = [Microsoft][ODBC SQL Server
Driver][SQL Server]The text, ntext, and image data types cannot be
compared or sorted, except when using IS NULL or LIKE operator.
(SQLExecute[306] at ext\pdo_odbc\odbc_stmt.c:133) [3] = 42000 )
--
Edit this bug report at http://bugs.php.net/?id=36561edit=1
#36602 [Opn-Csd]: MySQL server has gone away with PDO::ATTR_PERSISTENT = true
ID: 36602 Updated by: [EMAIL PROTECTED] Reported By: nerve at gmx dot net -Status: Open +Status: Closed Bug Type: PDO related Operating System: Gentoo Linux PHP Version: 5.1.2 New Comment: Fixed in CVS. Previous Comments: [2006-03-13 15:47:31] damien dot harper at gmail dot com I'm running a debian box dual Xeon 2 gigs of RAM and powering Apache 2.2.0, PHP 5.1.2, MySQL 5.0.18, PDO_mysql 5.0.18 and getting the same issues. It would be really nice to be able to set the persistent connections lifetime. Otherwise, PDO should be smart enough to autodetect dead connections and avoid to return them. [2006-03-08 15:54:03] nerve at gmx dot net Or an other idea, how about the posibility to specify a time after which the persistent connection is closed ? (Aka timeout). I want beleve that mysql is the only pdo backend with useles persistent connections. I (and every other ho is using persistent connections for a big or important aplication) thank you for a good solution. Daniel Heule [2006-03-08 15:48:27] nerve at gmx dot net And what is abaut a new method to destroy the death persistent object ? So every user can destroy it and recreate the persistent connection without restarting the webserver ? Not all php users have the choise to restart the webserver if a persistent connection is going to hell ? Thank you Daniel [2006-03-04 23:56:31] nerve at gmx dot net Thank you for your good help ;-(, clearly it's in the docu, but in this case persistent connections are useles ;-( [2006-03-04 22:04:38] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php As this is documented clearly in mysql documentation - bogus. The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/36602 -- Edit this bug report at http://bugs.php.net/?id=36602edit=1
#36652 [Opn-Csd]: Prepared statements killing script
ID: 36652
Updated by: [EMAIL PROTECTED]
Reported By: shadda at gmail dot com
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: Debian 3.1
PHP Version: 5.1.2
New Comment:
postgres has a particularly poor C API for communicating type
information in prepared statements.
You most likely need to add some kind of nasty cast for those
statements to work correctly, or sidestep the issue by preparing your
statement using:
$stmt = $db-prepare($sql,
array(PDO::PGSQL_ATTR_DISABLE_NATIVE_PREPARED_STATEMENT = true));
or, using the very latest snap:
$stmt = $db-prepare($sql, array(PDO::ATTR_EMULATE_PREPARES = true));
If you can repeat the silent-death of your script, please re-open this
bug report. I'm assuming that it's fixed because your additional
comments have working error information.
Previous Comments:
[2006-03-10 00:05:54] shadda at gmail dot com
Excuse the delay; I'm using PDO_PGSQL driver, and yes I've tried the
latest snapshot from snaps.php.net.
I just built it, and tested the code.
Gluttony:/home/shadda/php5.1-200603081930# php -r '
try {
$db = new PDO(pgsql:host=localhost;dbname=carbonix, xoom,
1914);
$db-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$q = $db-prepare(select ?);
$q-execute( array(1) ); var_dump($q-fetch());
} catch (Exception $e) { echo $e-getMessage(); }'
Returns:
SQLSTATE[42P18]: Indeterminate datatype: 7 ERROR: could not determine
data type of parameter
[2006-03-08 08:28:12] [EMAIL PROTECTED]
What driver are you using with PDO ?
Is it PDO_OCI or PDO_MYSQL or something else?
Did you try CVS snapshot from http://snaps.php.net?
[2006-03-08 06:19:42] shadda at gmail dot com
Description:
Using prepared statements causes my script to die, in two ways
depending on how I use them. If I use bindParam() the script dies
silently (no error, no exception thrown, even with PDO::ATTR_ERRMODE
set to ERRMODE_EXCEPTION) and I am unable to output anything (above or
below). When I pass the parameter through PDOStatement::execute(), I
receive the following error:
SQLSTATE[42P18]: Indeterminate datatype: 7 ERROR: could not determine
data type of parameter $1
Reproduce code:
---
?php
//First Example
$query = $db-prepare(select font_name, path from fonts_list where id
= ?);
$query-execute( array($_GET['foo']) );
//Produces error (see above)
//Second example
$query = $db-prepare(Select font_name, path from fonts_list where id
= :id);
$query-bindParam(':id', $id);
$id = $_GET['foo'];
$query-execute();
//Kills the script. No Error. Nothing error log.
--
Edit this bug report at http://bugs.php.net/?id=36652edit=1
#36681 [Ver]: Deferred constraints do not raise an exception on commit
ID: 36681
Updated by: [EMAIL PROTECTED]
Reported By: ce at netage dot bg
Status: Verified
Bug Type: PDO related
Operating System: Linux Windows
PHP Version: 5.1.2
New Comment:
My guess is that this patch will fix this issue, but I haven't tried
it:
Index: pgsql_driver.c
===
RCS file: /repository/php-src/ext/pdo_pgsql/pgsql_driver.c,v
retrieving revision 1.53.2.14
diff -u -p -r1.53.2.14 pgsql_driver.c
--- pgsql_driver.c 9 Apr 2006 08:17:50 - 1.53.2.14
+++ pgsql_driver.c 9 Apr 2006 08:23:52 -
@@ -470,6 +470,7 @@ static int pdo_pgsql_transaction_cmd(con
if (PQresultStatus(res) != PGRES_COMMAND_OK) {
ret = 0;
+ pdo_pgsql_error(dbh, PQresultStatus(res),
pdo_pgsql_sqlstate(res));
}
PQclear(res);
Previous Comments:
[2006-03-10 17:52:04] [EMAIL PROTECTED]
I'm reproducing the bug on Windows XP with PHP 5.1.2.
[2006-03-10 14:32:03] ce at netage dot bg
Description:
When using deferred constraints in postgresql, the commit statement
doesn't raise exception on constraint violation
Reproduce code:
---
create table parent (id integer not null primary key);
create table child (parent integer not null references parent(id)
deferrable);
$dbh = new PDO('pgsql:dbname=test;host=localhost');
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$dbh-beginTransaction();
$dbh-exec('SET CONSTRAINTS ALL DEFERRED');
$dbh-exec('insert into child VALUES (1)');
$dbh-commit();
Expected result:
PHP Fatal error: Uncaught exception 'PDOException' with message
'SQLSTATE[23503]: Foreign key violation: 7 ERROR: insert or update on
table child violates foreign key constraint child_parent_fkey
Actual result:
--
nothing
--
Edit this bug report at http://bugs.php.net/?id=36681edit=1
#36890 [Opn-Fbk]: PDO does not throw Exception
ID: 36890
Updated by: [EMAIL PROTECTED]
Reported By: akorthaus at web dot de
-Status: Open
+Status: Feedback
Bug Type: PDO related
Operating System: Linux 2.4.32 (gentoo)
PHP Version: 5.1.2
New Comment:
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
Previous Comments:
[2006-03-28 13:59:20] akorthaus at web dot de
Description:
The following code leads to a Unknown Command Error (because I tried
to use PDO with a 5.0 libmysql to connect to a 3.23 mysqld), but for
any reason this does not throw an Ecxeption, though I used:
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
Why doesn't PDO throw an Exception here?
Reproduce code:
---
?php
try {
$dbh = new PDO('mysql:host=localhost;dbname=test', 'user', 'pass');
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$result = $dbh-query('SELECT * FROM test');
var_dump($dbh-errorInfo());
}
catch(PDOException $e){
die($e-getMessage());
}
?
Expected result:
should throw a PDOEception (Unknown Command), which is caused by
PDO::query().
Actual result:
--
Does not throw any exception, only $dbh-errorInfo() gives some info
here.
$dbh-query() return FALSE
$dbh-errorInfo() returns error Unknown Command
$dbh-getAttribute(PDO::ATTR_ERRMODE) returns 2
which is == PDO::ERRMODE_EXCEPTION
shouldn't PDO throw an Exception here? Seems to ignore the errormode
set by $dbh-setAttribute(). Before calling $dbh-query() and after
calling $dbh-setAttribute() $dbh-errorInfo() returns no error.
I started a thread on php.pecl.dev last week about a problem with using
PDO_MYSQL linked against a 5.0 libmysql with a 3.23 mysqld. The reason
for the error seems to be, that PDO_MYSQL uses prepare internally,
which is not supported by mysqld 4.1:
http://marc.theaimsgroup.com/?t=1143141r=1w=2
--
Edit this bug report at http://bugs.php.net/?id=36890edit=1
#36662 [Opn-Bgs]: PDO_ODBC-MSSQL: exec() returns false when doing DELETE on nonexisting row
ID: 36662 Updated by: [EMAIL PROTECTED] Reported By: gustav at cst dot co dot za -Status: Open +Status: Bogus Bug Type: PDO related Operating System: Microsoft Windows XP PHP Version: 5.1.2 New Comment: Duplicate of #36632. Previous Comments: [2006-03-09 11:44:54] gustav at cst dot co dot za The problem seems more general than I realised. an UPDATE affecting 0 rows *also* returns FALSE instead of int(0). This following error message is returned in both cases: SQLExecDirect[0] at ext\pdo_odbc\odbc_driver.c:230 NOTE: A temporary workaround is to use query() instead of exec(). [2006-03-09 08:02:47] gustav at cst dot co dot za Description: Hi, I use PDO_ODBC (linked against Win32 ODBC) to connect to MSSQL. Webserver is IIS 5. When I run a DELETE statement that tries to delete a nonexisting row, exec() returned FALSE instead of int(0). An existing row deletes fine. Reproduce code: --- ?php $dsn = 'odbc:database'; $user = 'user'; $password = 'pass'; $dbh = new PDO($dsn, $user, $password); $result = $dbh-exec(DELETE FROM radio WHERE station_id = 10); if ($result===false) echo FALSE; else $result; ? Expected result: 0 Actual result: -- FALSE -- Edit this bug report at http://bugs.php.net/?id=36662edit=1
#35386 [Asn-Opn]: first row is null
ID: 35386
Updated by: [EMAIL PROTECTED]
Reported By: slapaf at hotmail dot com
-Status: Assigned
+Status: Open
Bug Type: PDO related
Operating System: winxp sp2
PHP Version: 5CVS-2006-12-02 (snap)
Assigned To: wez
New Comment:
Looking for someone to maintain the firebird driver.
Previous Comments:
[2006-03-21 16:11:10] salbefe at inf dot upv dot es
I have the same problem in Windows 2003 SP1.
[2006-03-10 09:49:11] astro101 at hotmail dot com
Yes had same problem WinXP SP2 Firebird 1.5.3 and firebird 2 and PHP
5.1.2, PHP5.1.3RC1, PHP5.1.3RC2.
[2006-02-11 17:25:16] thomas at last-it dot de
same problem on linux, php 5.1.2
I tried to debug the problem, but imho the problem is strange.
The reason why the first row is null is as following:
file: ext/pdo/pdo_stmt.c
line: 532
code
case PDO_PARAM_STR:
if (value !(value_len == 0 stmt-dbh-oracle_nulls ==
PDO_NULL_EMPTY_STRING)) {
ZVAL_STRINGL(dest, value, value_len, !caller_frees);
if (caller_frees) {
caller_frees = 0;
}
break;
}
default:
ZVAL_NULL(dest);
/code
With the first returned row from DB the first if clause above evaluates
to false.
so ZVAL_NULL is called. thats the reason for the null values in the
first result set.
Normally should value point to the argument ptr of the
firebird_stmt_get_col function (in firebird_statement.c).
gdp says that ptr is filled with the data out of DB properly.
So why is value not the same as ptr and why is this only in the
first result set??
greetz Thomas
[2006-02-08 18:49:28] turyak at gmail dot com
yep, experiencing same problem..
php 5.1.2, firebird 1.5.2
is there solution already?
[2005-11-25 11:38:32] slapaf at hotmail dot com
Description:
When using PDO for simple query in Firebird it returns first row as
null.
I've tried using ADODB for control and it returns the correct results.
Reproduce code:
---
$dbh = new PDO(firebird:dbname=localhost:test.fdb,,**);
$sql='SELECT EVENT_NAME FROM EVENTS';
foreach($dbh-query($sql) as $row){
print 'pre'.gettype($row['EVENT_NAME']).' :
'.$row['EVENT_NAME'];
}
Expected result:
string : name 1
string : name 2
string : name 3
string : name 4
Actual result:
--
NULL :
string : name 2
string : name 3
string : name 4
--
Edit this bug report at http://bugs.php.net/?id=35386edit=1
#35671 [Asn-Csd]: Named parameters not working in PDO_ODBC
ID: 35671
Updated by: [EMAIL PROTECTED]
Reported By: mknobloch at midstate dot edu
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: Windows 2003 SP1
PHP Version: 5.1.2
Assigned To: wez
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
See also http://pecl.php.net/bugs/bug.php?id=6504.
Previous Comments:
[2006-03-09 10:09:39] alien at mosfasad dot ru
No bug in sqlite2 and sqlite Driver.
$oPdo = new PDO('sqlite:test.lite');
$oStat = $oPdo-prepare(INSERT INTO php_qqq (name, value) VALUES (?,
?));
$oStat-execute(array('1','444'));
in table php_qqq have values (1 and 444);
[2006-03-09 09:54:45] alien at mosfasad dot ru
bug exists in snapshot of 09 Mar 2006 04:32:09 +0100
[2006-03-02 18:32:00] bubblenut at gmail dot com
I'm getting this problem with all parameters (named and otherwise) with
PDO_MYSQL 1.0.1 with both php-5.1.2 and php-5.1.3-dev on Linux (Kubuntu
Breezy)
[2006-02-17 19:02:14] dkrook at hotmail dot com
I've encountered the same problem with DB2 and '?' parameter markers.
http://marc.theaimsgroup.com/?l=php-dbm=114014376609292w=2
[2006-02-16 00:20:43] stoens at activegrid dot com
I am seeing the same thing with the OCI and the ODBC drivers on Windows
and Linux (FC4). Same PHP version.
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35671
--
Edit this bug report at http://bugs.php.net/?id=35671edit=1
#36342 [Asn-Csd]: missing values on recordset with a very simple request
ID: 36342
Updated by: [EMAIL PROTECTED]
Reported By: teissierb at hotmail dot com
-Status: Assigned
+Status: Closed
Bug Type: PDO related
Operating System: WIN32
PHP Version: 5.1.2
Assigned To: wez
New Comment:
This bug has been fixed in CVS.
Snapshots of the sources are packaged every three hours; this change
will be in the next snapshot. You can grab the snapshot at
http://snaps.php.net/.
Thank you for the report, and for helping us make PHP better.
Fixed in CVS; try the next snapshot.
Previous Comments:
[2006-03-15 16:03:38] [EMAIL PROTECTED]
This is actually a limitation of ODBC; long columns must be the last
columns bound in a query. It is possible for PDO to workaround this by
using an alternate, slower, approach to fetching the data. In the long
run, you are better off making sure you query the big columns out last.
[2006-03-08 00:04:17] marshmallow007 at hotmail dot com
I'have the same bug for the 1 row with Firebird but not with MySQL!
Firebird:
Array ( [INDEX] = [DATE] = [TEXTE] = )
MySQL:
Array ( [INDEX] = 1 [DATE] = 1969-05-07 [TEXTE] = marshmallow)
[2006-02-23 01:07:14] travis at raybold dot com
i've got a simpler test case...
ON Windows XP, IIS6, PHP 5.1.2 (With the 5.1.0 php_pdo.dll and
php_pdo_odbc.dll to avoid bug #35671), SQL Server 2000 accessed through
PDO_ODBC.
creating a simple table and inserting one row as follows:
--
CREATE TABLE zTest_TBL (
Test varchar (256),
TestID int
)
INSERT INTO zTest_TBL ( Test ) VALUES ('test')
--
then try to query with:
--
$oConnection = new PDO($sDSN);
foreach($oConnection-query('SELECT * FROM zTest_TBL ') as $aRow) {
print_r($aRow);
}
--
returns:
--
Array ( [Test] = [0] = [TestID] = [1] = )
--
expected:
--
Array ( [Test] = test [0] = test [TestID] = [1] = )
--
Note: reducing the size to 255 makes it work as expected. it also works
as expected if there is just the one field, regardless of the size.
adding another field, be it integer or varchar kills the long field. I
tested with the 5.1.2 php_pdo.dll and php_pdo_odbc.dll with the same
results.
[2006-02-10 15:18:28] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-02-09 15:27:59] teissierb at hotmail dot com
Description:
On SQL Server 2005 Express (free), using Windows XP, Wamp 1.6.0 (php
5.1.1) and PDO ODBC:
With a simple table PDO doesn't return what I expect him to. Might be
dued to the mix of varchar and (small, tiny)int.
Reproduce code:
---
create table T (
[A] varchar(80) NOT NULL,
[B] tinyint NOT NULL,
[C] varchar(100) NOT NULL,
[D] smallint NOT NULL,
[E] varchar(1024) NOT NULL,
[F] varchar(255) NOT NULL,
[G] varchar(255) NOT NULL,
[H] varchar(1000) NOT NULL,
[I] varchar(100) NOT NULL,
[J] tinyint NOT NULL,
[K] varchar(255) NULL
)
insert into T values ('A', '1', 'C', '2', 'E', 'F', 'G', 'H', 'I', '3',
'K')
//
try {
$db = new PDO('odbc:Driver={SQL
Server};Server=HOST\INSTANCENAME;Database=;', user, pass);
} catch( PDOException $e ){
die( $e-getMessage() );
}
foreach( $db-query(SELECT * FROM T , PDO::FETCH_NUM) as $row ) {
echo pre; print_r( $row );echo /pre;
}
Expected result:
[0] = A
[1] = 1
[2] = C
[3] = 2
[4] = E
[5] = F
[6] = G
[7] = H
[8] = I
[9] = 3
[10] = K
Actual result:
--
[0] = A
[1] = 1
[2] = C
[3] = 2
[4] =
[5] = F
[6] = G
[7] =
[8] = I
[9] = 3
[10] = K
--
Edit this bug report at http://bugs.php.net/?id=36342edit=1
#36342 [Asn]: missing values on recordset with a very simple request
ID: 36342
Updated by: [EMAIL PROTECTED]
Reported By: teissierb at hotmail dot com
Status: Assigned
Bug Type: PDO related
Operating System: WIN32
PHP Version: 5.1.2
Assigned To: wez
New Comment:
This is actually a limitation of ODBC; long columns must be the last
columns bound in a query. It is possible for PDO to workaround this by
using an alternate, slower, approach to fetching the data. In the long
run, you are better off making sure you query the big columns out last.
Previous Comments:
[2006-03-08 00:04:17] marshmallow007 at hotmail dot com
I'have the same bug for the 1 row with Firebird but not with MySQL!
Firebird:
Array ( [INDEX] = [DATE] = [TEXTE] = )
MySQL:
Array ( [INDEX] = 1 [DATE] = 1969-05-07 [TEXTE] = marshmallow)
[2006-02-23 01:07:14] travis at raybold dot com
i've got a simpler test case...
ON Windows XP, IIS6, PHP 5.1.2 (With the 5.1.0 php_pdo.dll and
php_pdo_odbc.dll to avoid bug #35671), SQL Server 2000 accessed through
PDO_ODBC.
creating a simple table and inserting one row as follows:
--
CREATE TABLE zTest_TBL (
Test varchar (256),
TestID int
)
INSERT INTO zTest_TBL ( Test ) VALUES ('test')
--
then try to query with:
--
$oConnection = new PDO($sDSN);
foreach($oConnection-query('SELECT * FROM zTest_TBL ') as $aRow) {
print_r($aRow);
}
--
returns:
--
Array ( [Test] = [0] = [TestID] = [1] = )
--
expected:
--
Array ( [Test] = test [0] = test [TestID] = [1] = )
--
Note: reducing the size to 255 makes it work as expected. it also works
as expected if there is just the one field, regardless of the size.
adding another field, be it integer or varchar kills the long field. I
tested with the 5.1.2 php_pdo.dll and php_pdo_odbc.dll with the same
results.
[2006-02-10 15:18:28] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-02-09 15:27:59] teissierb at hotmail dot com
Description:
On SQL Server 2005 Express (free), using Windows XP, Wamp 1.6.0 (php
5.1.1) and PDO ODBC:
With a simple table PDO doesn't return what I expect him to. Might be
dued to the mix of varchar and (small, tiny)int.
Reproduce code:
---
create table T (
[A] varchar(80) NOT NULL,
[B] tinyint NOT NULL,
[C] varchar(100) NOT NULL,
[D] smallint NOT NULL,
[E] varchar(1024) NOT NULL,
[F] varchar(255) NOT NULL,
[G] varchar(255) NOT NULL,
[H] varchar(1000) NOT NULL,
[I] varchar(100) NOT NULL,
[J] tinyint NOT NULL,
[K] varchar(255) NULL
)
insert into T values ('A', '1', 'C', '2', 'E', 'F', 'G', 'H', 'I', '3',
'K')
//
try {
$db = new PDO('odbc:Driver={SQL
Server};Server=HOST\INSTANCENAME;Database=;', user, pass);
} catch( PDOException $e ){
die( $e-getMessage() );
}
foreach( $db-query(SELECT * FROM T , PDO::FETCH_NUM) as $row ) {
echo pre; print_r( $row );echo /pre;
}
Expected result:
[0] = A
[1] = 1
[2] = C
[3] = 2
[4] = E
[5] = F
[6] = G
[7] = H
[8] = I
[9] = 3
[10] = K
Actual result:
--
[0] = A
[1] = 1
[2] = C
[3] = 2
[4] =
[5] = F
[6] = G
[7] =
[8] = I
[9] = 3
[10] = K
--
Edit this bug report at http://bugs.php.net/?id=36342edit=1
#36492 [Asn]: stream_filter_register cause memory leaks
ID: 36492
Updated by: [EMAIL PROTECTED]
Reported By: sqchen at citiz dot net
Status: Assigned
Bug Type: Streams related
Operating System: redhat 7.3
PHP Version: 5.1.2
-Assigned To: wez
+Assigned To: pollita
New Comment:
assigned to the other maintainer
Previous Comments:
[2006-02-23 14:44:59] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-02-23 06:56:46] sqchen at citiz dot net
I think it is actully stream_filter_append() function cause memory
leaks,
attention: php-5.1.1 will not cause memory leaks, I have compare the
source code of php-5.1.1 with php-5.1.2, and I found there are only
little difference in ~\main\streams\filter.c line 207-208.
if (brigade-tail == bucket) {
return;
php-5.1.1 have not, bug php-5.1.2 have.
[2006-02-23 06:33:56] sqchen at citiz dot net
Description:
stream_filter_register cause memory leaks when the php version is 5.1.2
and add --enable-debug parameter
Reproduce code:
---
?php
class strtolower_filter extends php_user_filter{}
stream_filter_register(strtolower, strtolower_filter);
$fp = fopen(foo-bar.txt, w);
stream_filter_append($fp, strtolower);
fwrite($fp, Line1\n);
fwrite($fp, WORD - 2\n);
fwrite($fp, Easy As 123\n);
fclose($fp);
readfile(foo-bar.txt);
?
Actual result:
--
[Thu Feb 23 13:32:38 2006] Script: 'stream_filter_register.php'
/home/sqchen/sqchen/php-5.1.2/main/streams/filter.c(78) : Freeing
0x083EEC14 (32 bytes), script=stream_filter_register.php
Last leak repeated 2 times
=== Total 3 memory leaks detected ===
--
Edit this bug report at http://bugs.php.net/?id=36492edit=1
#36344 [Opn-Bgs]: MSSQL Driver does not support multiple row sets
ID: 36344 Updated by: [EMAIL PROTECTED] Reported By: thomas at changepp dot co dot uk -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows PHP Version: 5.1.2 New Comment: Use the ODBC driver instead; the libraries used by the MSSQL driver are no longer supported by microsoft. Previous Comments: [2006-02-09 17:40:23] thomas at changepp dot co dot uk Description: Warning: PDOStatement::nextRowset() [function.nextRowset]: SQLSTATE[IM001]: Driver does not support this function: driver does not support multiple rowsets. The MSSQL driver should support multiple rowsets since Stored Procedures in MSSQL can return them. -- Edit this bug report at http://bugs.php.net/?id=36344edit=1
#36281 [Asn-Bgs]: bindParam not working with LIKE '%:foo%'
ID: 36281
Updated by: [EMAIL PROTECTED]
Reported By: vendor at visv dot net
-Status: Assigned
+Status: Bogus
Bug Type: PDO related
Operating System: Linux
PHP Version: 5.1.2
Assigned To: wez
New Comment:
That is not a valid parameter definition.
Previous Comments:
[2006-02-04 18:21:16] vendor at visv dot net
No change nor improvement with
http://snaps.php.net/php5.1-latest.tar.gz on Feb 4. 12:20PM
[2006-02-04 12:48:08] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2006-02-04 05:35:05] vendor at visv dot net
Description:
$q = SELECT id, name FROM test WHERE name like '%:foo%';
$s = carrot;
$dbh = new PDO('mysql:...', $user, $pass);
$sth = $dbh-prepare($q);
$sth-bindParam(':foo', $s);
$sth-execute()
while ($r = $sth-fetch()) {
print_r($r);
}
the above does not work. Adding PDO::PARAM_STR, and the
length argument do not help matters.
simply embedding $s in place of :foo does work. It also
works fine if I leave off the '% and %' parts
and $s == the column value. It just seems bindParam()
cannot cope with the '% %' parts in the query.
I do not find similar in your bugtracking system, nor
in user supplied notes (currently there are none).
Thanks.
Reproduce code:
---
See description.
--
Edit this bug report at http://bugs.php.net/?id=36281edit=1
#26495 [Sus]: Using WebSite Pro 2.5 with ISAPI, cookies are not working
ID: 26495 Updated by: [EMAIL PROTECTED] Reported By: maura at fastwebnet dot it Status: Suspended Bug Type: Other web server Operating System: win nt4 sp6a PHP Version: 6CVS, 5CVS, 4CVS Assigned To: wez New Comment: Stop assigning this to me; I've unassigned it multiple times. I am not going to do anything about it. Previous Comments: [2003-12-02 01:44:23] [EMAIL PROTECTED] Those two opcodes are MS specific ISAPI codes to determine the webroot and send headers respectively. Currently, our ISAPI module relies on the web server implementing those opcodes. It shouldn't be too difficult to use the traditional HSE_REQ_SEND_RESPONSE_HEADER opcode as a fallback for the latter code. Speaking for myself, I don't have the time to do this, but I don't expect it to take much more than an hour or so to implement; maybe one of the other isapi guys has the time? [2003-12-01 20:03:04] maura at fastwebnet dot it Description: I use O'Reilly WebSite Pro 2.5 and php4isapi.dll All is working but no cookies are sent to browser. Changes made in php.ini-recommended are: doc_root = c:\webroot Reproduce code: --- ?php setcookie (testcookie,text,time()+3600); ? Expected result: That cookie is sent to the browser Actual result: -- server.log report: ** REQUEST from 192.168.0.1 ** REQ: m=GET u=/prova/provaphp.php a= p= Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */* Accept-Language: en-us Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 4.0) Host: www.mysite.net Connection: Keep-Alive Cookie: userid=maurissia; passw=maurissia; w=110099120118110121122113106 Request decoding complete... node=C:/Siti/Mokadom/prova/provaphp.php: params= args= Calling ISAPI/ISA C:\PHP\sapi\php4isapi.dll [ISAPI] url /prova/provaphp.php [ISAPI] args Associated ISA, using bogus MS path info ISAPI: ServerSupportFunction() called with unknown opcode 1012 ISAPI: ServerSupportFunction() called with unknown opcode 1016 -- Edit this bug report at http://bugs.php.net/?id=26495edit=1
#35793 [Asn-Fbk]: General error: 2050
ID: 35793 Updated by: [EMAIL PROTECTED] Reported By: deadman_great at mail dot ru -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: RH Fedora Core 2 PHP Version: 5CVS-2005-12-25 (snap) Assigned To: wez New Comment: Try it with mysql 4.x. If it works fine there, it's a mysql 5 problem that should be reported to the mysql folks. Previous Comments: [2005-12-27 11:29:27] deadman_great at mail dot ru Installed latest mysql (v5.0.17). Same error. [2005-12-26 23:22:21] [EMAIL PROTECTED] Almost certainly a mysql bug. Check in with the mysql bug database. [2005-12-26 17:06:35] [EMAIL PROTECTED] Assigned to the PDO maintainer. [2005-12-25 19:21:12] deadman_great at mail dot ru Tried php5.1-200512251730, - same result. [2005-12-25 17:37:56] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.1-latest.tar.gz For Windows: http://snaps.php.net/win32/php5.1-win32-latest.zip The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/35793 -- Edit this bug report at http://bugs.php.net/?id=35793edit=1
#35793 [Asn-Fbk]: General error: 2050
ID: 35793
Updated by: [EMAIL PROTECTED]
Reported By: deadman_great at mail dot ru
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: RH Fedora Core 2
PHP Version: 5CVS-2005-12-25 (snap)
Assigned To: wez
New Comment:
Almost certainly a mysql bug. Check in with the mysql bug database.
Previous Comments:
[2005-12-26 17:06:35] [EMAIL PROTECTED]
Assigned to the PDO maintainer.
[2005-12-25 19:21:12] deadman_great at mail dot ru
Tried php5.1-200512251730, - same result.
[2005-12-25 17:37:56] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-12-24 18:30:13] deadman_great at mail dot ru
OK, without OO:
?
$pdo = new PDO('mysql:host=localhost;dbname=mydb','login','pass');
$pdo-setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_WARNING);
function Query ()
{
global $pdo;
$query = 'SELECT `created`, to_days(from_unixtime(`created`)) as
`day`,count(`id`) as `count` '.
'FROM `orders` '.
'WHERE `partner`=:partner '.
'AND `created`=:date '.
'GROUP BY `day`';
$vars = array(':partner'=9,':date'=1132797644);
$stm = $pdo-Prepare($query);
$stm-Execute($vars);
return $stm;
}
$result = Query();
foreach ($result as $day)
{
print_r($day); echo 'hr';
}
$result = Query();
foreach ($result as $day)
{
print_r($day); echo 'hr';
}
$result = Query();
foreach ($result as $day)
{
print_r($day); echo 'hr';
}
?
SQL:
CREATE TABLE `orders` (
`id` int(10) unsigned NOT NULL auto_increment,
`state` tinyint(3) unsigned NOT NULL default '0',
`partner` int(10) unsigned NOT NULL,
`created` int(10) unsigned NOT NULL default '0',
`completed` int(10) unsigned default NULL,
`count` tinyint(3) unsigned NOT NULL,
`cost` float(11,2) unsigned NOT NULL default '0.00',
`zip` int(10) unsigned default NULL,
`region` varchar(80) default NULL,
`city` varchar(120) default NULL,
`street` varchar(255) default NULL,
`house` varchar(32) default NULL,
`building` varchar(32) default NULL,
`apartment` varchar(32) default NULL,
`name` varchar(255) default NULL,
`surname` varchar(255) default NULL,
`patronymic` varchar(255) default NULL,
`mail` varchar(120) default NULL,
`comments` text,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
INSERT INTO `orders` VALUES
(1,0,9,1134531133,1134931138,2,20,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES
(2,4,9,1134911133,1134911139,1,10,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES
(3,1,9,1134811133,1134811137,4,40,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES
(4,3,9,1134711133,1134711533,1,10,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES
(5,4,9,1134511131,1134511138,1,10,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL);
INSERT INTO `orders` VALUES
(6,1,0,1135521534,NULL,1,10,121231,'test','test','test','12',NULL,NULL,'test','test','test','[EMAIL
PROTECTED]',NULL);
INSERT INTO `orders` VALUES
(7,0,9,1134522614,NULL,1,10,354354,'test2','test2','test2','12',NULL,NULL,'test2','test2','test2','[EMAIL
PROTECTED]',NULL);
[2005-12-24 03:15:35] deadman_great at mail dot ru
Description:
Current script works fine on localhost (winxp), and throw errors on
remote server (rh-fedora).
Software:
Local: winxp-sp2,php-5.1.1,mysql-5.0.3
Remote: fedora-c2,php-5.1.1,mysql-5.0.9
Reproduce code:
---
$query = 'SELECT `created`, to_days(from_unixtime(`created`)) as
`day`,count(`id`) as `count` FROM `orders` WHERE `partner`=:partner AND
`created`=:date GROUP BY `day`';
$vars = array(':partner'=9,':date'=1132797644);
$stm = $pdo-Prepare($query);
$result = $stm-Execute($vars);
foreach ($result as $day) // LINE-123
{
...
}
Expected result:
Rows.
Actual result:
--
Warning: main() [function.main]: SQLSTATE[HY000]: General error: 2050
in ... on line 123
--
Edit this bug report at http://bugs.php.net/?id=35793edit=1
#35795 [Asn]: MySQL driver quotes strings incorrectly with ANSI SQL mode
ID: 35795
Updated by: [EMAIL PROTECTED]
Reported By: spaze-bugs at exploited dot cz
Status: Assigned
Bug Type:PDO related
PHP Version: 5.1.1
Assigned To: wez
New Comment:
It's not a compile time option.
If your environment supports native statements, they will work. If it
doesn't, PDO will emulate them.
Using prepared statements is strongly recommended over manually
building queries, for performance and readability, and because it
reduces the risk of SQL injection.
Previous Comments:
[2005-12-25 17:37:21] [EMAIL PROTECTED]
Assigned to the PDO maintainer.
[2005-12-25 13:19:56] spaze-bugs at exploited dot cz
According to MySQL manual
A string is a sequence of characters, surrounded by either single
quote (') or double quote () characters. [...] If the server SQL
mode has ANSI_QUOTES enabled, string literals can be quoted only with
single quotes.
So the quoter should use single quotes with emulated prepared
statements (instead of double quotes) to be compatible with both SQL
modes.
Thus, reopening.
[2005-12-24 21:54:09] spaze-bugs at exploited dot cz
PDO has no way to know, what I've done, you're right. But I don't have
a way to tell PDO that the environment got changed and that it should
quote a little different. I don't mean that it should do runtime checks
(like SELECT @@sql_mode), but some specific attibute, as I've already
written.
Thanks for pointing me to the native prepared statements, but as I've
read the source a little, I see that whether to use native prepared
statements or not, is a compile-time option and it's not exposed by ie.
phpinfo(). So some kind of end-user has no way to know, if native
prepared statements are used or not, especially if he's using some
precompiled binary ie. Windows distribution. Am I right?
Well, it seems to me that a solution to my problem with quoting in ANSI
mode is turning off the ANSI mode (and quote column names with backtick)
more than native prepare statements.
[2005-12-24 19:04:31] [EMAIL PROTECTED]
When you issue queries that change the database session environment
like that, PDO has no way to know what you've done without performing
all kinds of checks on each query.
There's no reason to slow down the common case for everyone else.
All your problems are solved by using real prepared statements, where
explicit quoting is not required.
[2005-12-24 18:58:36] spaze-bugs at exploited dot cz
Description:
I'm running MySQL in ANSI SQL mode [1], which includes the ANSI_QUOTES
mode. That means
/Treat as an identifier quote character (like the ` quote
character) and not as a string quote character./
When I use ie. prepared statements I get these queries in the general
query log
INSERT INTO t_images (hash, width, height, imageformat_id)
VALUES (ff2204530628d3c589843ef0b37d344a, 500, 500, NULL)
Which is bad, the strings (the hash) in the VALUES (...) section should
be quoted by the ' character. Don't know what would be the best
solution, but I think some documented MySQL specific PDO attribute
would be Ok.
Thanks for reviewing this issue.
[1] http://dev.mysql.com/doc/refman/4.1/en/server-sql-mode.html
Reproduce code:
---
$dbh = new PDO('mysql:host=mysql41;dbname=test', 'root', '');
$dbh-exec(SET SESSION sql_mode='ANSI');
echo $dbh-quote('foo');
Expected result:
'foo'
Actual result:
--
foo
--
Edit this bug report at http://bugs.php.net/?id=35795edit=1
#35795 [Opn-Bgs]: MySQL driver quotes strings incorrectly with ANSI SQL mode
ID: 35795
Updated by: [EMAIL PROTECTED]
Reported By: spaze-bugs at exploited dot cz
-Status: Open
+Status: Bogus
Bug Type:PDO related
PHP Version: 5.1.1
New Comment:
When you issue queries that change the database session environment
like that, PDO has no way to know what you've done without performing
all kinds of checks on each query.
There's no reason to slow down the common case for everyone else.
All your problems are solved by using real prepared statements, where
explicit quoting is not required.
Previous Comments:
[2005-12-24 18:58:36] spaze-bugs at exploited dot cz
Description:
I'm running MySQL in ANSI SQL mode [1], which includes the ANSI_QUOTES
mode. That means
/Treat as an identifier quote character (like the ` quote
character) and not as a string quote character./
When I use ie. prepared statements I get these queries in the general
query log
INSERT INTO t_images (hash, width, height, imageformat_id)
VALUES (ff2204530628d3c589843ef0b37d344a, 500, 500, NULL)
Which is bad, the strings (the hash) in the VALUES (...) section should
be quoted by the ' character. Don't know what would be the best
solution, but I think some documented MySQL specific PDO attribute
would be Ok.
Thanks for reviewing this issue.
[1] http://dev.mysql.com/doc/refman/4.1/en/server-sql-mode.html
Reproduce code:
---
$dbh = new PDO('mysql:host=mysql41;dbname=test', 'root', '');
$dbh-exec(SET SESSION sql_mode='ANSI');
echo $dbh-quote('foo');
Expected result:
'foo'
Actual result:
--
foo
--
Edit this bug report at http://bugs.php.net/?id=35795edit=1
#35770 [WFx]: inconsistent method naming PDO::exec and PDOStatement::execute
ID: 35770 Updated by: [EMAIL PROTECTED] Reported By: fh at ez dot no Status: Wont fix Bug Type: PDO related Operating System: linux - gentoo PHP Version: 5.1.1 Assigned To: wez New Comment: They do different things; having the same name for these is not clever, and we're not going to change it. Previous Comments: [2005-12-22 14:28:20] fh at ez dot no You have aliases for this. At the very least fix this in PHP 6. Derick also noted another inconsistency in PDO: 13:15:25] Derick they also have beginTransaction, commit and rollback [2005-12-22 14:18:02] [EMAIL PROTECTED] too late to change this for BC reasons [2005-12-22 11:34:26] [EMAIL PROTECTED] Assigned to the maintainer. [2005-12-22 11:10:04] fh at ez dot no Description: The methods should either be named the same or given names that separate them more clearly. -- Edit this bug report at http://bugs.php.net/?id=35770edit=1
#35756 [Opn-Bgs]: ecalloc in fgets() does't not check its return value
ID: 35756
Updated by: [EMAIL PROTECTED]
Reported By: sqchen at citiz dot net
-Status: Open
+Status: Bogus
Bug Type: Filesystem function related
Operating System: redhat 7.3
PHP Version: 5.1.1
New Comment:
ecalloc, emalloc, erealloc and friends will never return NULL.
Previous Comments:
[2005-12-21 03:39:46] sqchen at citiz dot net
Description:
file ext/standard/file.c
line 1028
buf = ecalloc(len + 1, sizeof(char));
if (php_stream_get_line(stream, buf, len, line_len) == NULL) {
goto exit_failed;
}
here doesn't check the availablity of 'buf', so if ecalloc doesn't
calloc a memory, it will return NULL, it will cause some problem
Reproduce code:
---
$fp=fopen(1.txt, r);
fgets($fp, 2147483640);
on some platform, when ecalloc failed, it will return NULL, so
segmentation fault will prompt.
the same as fread function
--
Edit this bug report at http://bugs.php.net/?id=35756edit=1
#35719 [Asn-WFx]: com_event_sink fails under Apache
ID: 35719
Updated by: [EMAIL PROTECTED]
Reported By: csaba at alum dot mit dot edu
-Status: Assigned
+Status: Wont fix
Bug Type: COM related
Operating System: Win XP Pro
PHP Version: 5.1.1
Assigned To: wez
New Comment:
com_event_sink() and com_message_pump() are intended to be used in
standalone, single-threaded processes.
Previous Comments:
[2005-12-17 15:17:04] csaba at alum dot mit dot edu
Description:
Using com_event_sink when PHP 5.1.1 runs as a module leads to PHP
timing out and generating an ugly apache error.
I want to be able to start up IE as a COM object and load a page into
it so that I may parse the page. This makes sense because page
scraping (ie, using the contents returned by file_get_contents($url) or
other means) is not always tenable since scripts may substantially alter
the page. It is reasonable to wait for the page to load before starting
to deal with it, hence the need for com_event_sink.
If the below code is run as CLI PHP, then it works just fine: Run the
script, see an IE window come up, and then close that IE window to
terminate the script. You can get a record of what happened in the
file 'log' in the same directory as the script.
To see the bug, invoke the php file via a web server (I have been using
localhost/phpapp/theScript.php). The IE window will come up and php.net
will be loaded, but the last entry showing in the log file is:
com_event_sink has been called
Whether or not the IE window is closed, the script will time out and an
Apache HTTP Server error comes up apologizing for the inconvenience and
asking whether I'd like to tell Microsoft about the problem.
Csaba Gabor from Vienna
Reproduce code:
---
htmlheadtitlecom_event_sink test page/title/headbody
?php
$logFile = preg_replace(/[^\\/]+$/,
log,__FILE__);
file_put_contents($logFile, );
logit(Entered at: . date(H:i:s, j M Y e));
logit(Script: . __FILE__);
function logit($out) {
print $outbr\n;
file_put_contents($GLOBALS['logFile'],
$out\n, FILE_APPEND); }
class IESink {
public $terminated = false;
public function TitleChange($text) {
logit (title has changed: $text); }
public function DocumentComplete ($dom, $url) {
logit (doc has loaded: $url); }
public function OnQuit() {
logit (Quitting);
$this-terminated = true; } }
$ie = new COM(InternetExplorer.Application);
$ie-Visible = true;
$url = http://php.net;;
$ie-Navigate($url);
$sink = new IESink;
logit (About to sink);
com_event_sink($ie, $sink, DWebBrowserEvents2);
logit (com_event_sink has been called);
while (!$sink-terminated) {
com_message_pump(1000); }
logit (finished!);
?
/body/html
Expected result:
I expect to see events fire even when IE is brought up while it is
invoked under a web server.
Actual result:
--
IE Events don't fire, and there is an ugly error when PHP times out.
--
Edit this bug report at http://bugs.php.net/?id=35719edit=1
#35689 [Asn-Bgs]: Object of type com did not create an Iterator
ID: 35689
Updated by: [EMAIL PROTECTED]
Reported By: jamie dot layne at gmail dot com
-Status: Assigned
+Status: Bogus
Bug Type: COM related
Operating System: Windows Server 2003
PHP Version: 5.1.1
Assigned To: Wez
New Comment:
COM objects don't have that behaviour.
foreach() will ask the COM object for its default property and request
an iteratable interface from it.
If it can't get one, you get that error.
Previous Comments:
[2005-12-15 20:30:58] jamie dot layne at gmail dot com
Description:
The recommended way of iterating over COM as per Zend.com is to use the
foreach($com as $ob) method, as opposed to the old $com-Next()
approach.
This hasn't been working for objects of type COM or VARIANT.
Specs:
Windows Server 2003
PHP 5.1.1
Reproduce code:
---
?
-- Example --
$word = new COM(word.application);
foreach ($word as $obj) {
echo $obj. br;
}
?
Expected result:
List of properties for the desired COM object
Actual result:
--
Object of type com did not create an Iterator
Similar error:
Object of type variant did not create an Iterator
--
Edit this bug report at http://bugs.php.net/?id=35689edit=1
#35620 [Asn-Fbk]: access violation on odbc query
ID: 35620
Updated by: [EMAIL PROTECTED]
Reported By: humbads at alum dot mit dot edu
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-12-10 (snap)
Assigned To: wez
New Comment:
This could be the same bug as #35552.
I couldn't reproduce the issue, but did spot some code that might cause
something like this to happen.
Please try the next snapshot dated after this message to see if that
nailed it.
Previous Comments:
[2005-12-10 08:43:54] humbads at alum dot mit dot edu
The same crash occurs if the code is simply within a function, rather
than a class. Furthermore, the same crash occurs if another data source
is used, e.g. SQL Server.
myfunction();
function myfunction() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
}
[2005-12-10 08:24:07] humbads at alum dot mit dot edu
Description:
php-cgi.exe crashes with an access violation when using PDO ODBC to run
a simple query as given below. The code runs without error if not
enclosed in a class. It also runs without error if the query is run
without saving the return value in $result. The stack trace indicates a
crash when destroying the implicit prepared statement.
Reproduce code:
---
$mc = new MyClass;
class MyClass {
function MyClass() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
die(happy);
}
}
Expected result:
It should not crash when returning the result, or when running from
within a class.
Actual result:
--
[EMAIL PROTECTED]() + 0xb
odbc32.dll!CCriticalSection::Enter() + 0xf
[EMAIL PROTECTED]() + 0xf
[EMAIL PROTECTED]() + 0x23
[EMAIL PROTECTED]() + 0x2b
php_pdo_odbc.dll!odbc_stmt_dtor(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 56C
php_pdo.dll!free_statement(_pdo_stmt_t * stmt=0x00720448, void * * *
tsrm_ls=0x00323eb0) Line 2118 + 0x8C
php_pdo.dll!php_pdo_stmt_delref(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 2157 + 0xbC
php_pdo.dll!pdo_dbstmt_free_storage(_pdo_stmt_t * stmt=0x00720448,
void * * * tsrm_ls=0x00323eb0) Line 2162 + 0xf C
php5ts.dll!zend_objects_store_free_object_storage(_zend_objects_store
* objects=0x00328dc4, void * * * tsrm_ls=0x00323eb0) Line 83 + 0xb C
php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x00a232c0) Line 273
+ 0x13 C
[EMAIL PROTECTED]() + 0x26
Unhandled exception at 0x7c901010 (ntdll.dll) in php-cgi.exe:
0xC005: Access violation reading location 0x0018.
--
Edit this bug report at http://bugs.php.net/?id=35620edit=1
#35620 [Fbk]: access violation on odbc query
ID: 35620
Updated by: [EMAIL PROTECTED]
Reported By: humbads at alum dot mit dot edu
Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-12-10 (snap)
Assigned To: wez
New Comment:
I meant that this could be the same as #35592, not #35552.
Previous Comments:
[2005-12-14 05:58:57] [EMAIL PROTECTED]
This could be the same bug as #35552.
I couldn't reproduce the issue, but did spot some code that might cause
something like this to happen.
Please try the next snapshot dated after this message to see if that
nailed it.
[2005-12-10 08:43:54] humbads at alum dot mit dot edu
The same crash occurs if the code is simply within a function, rather
than a class. Furthermore, the same crash occurs if another data source
is used, e.g. SQL Server.
myfunction();
function myfunction() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
}
[2005-12-10 08:24:07] humbads at alum dot mit dot edu
Description:
php-cgi.exe crashes with an access violation when using PDO ODBC to run
a simple query as given below. The code runs without error if not
enclosed in a class. It also runs without error if the query is run
without saving the return value in $result. The stack trace indicates a
crash when destroying the implicit prepared statement.
Reproduce code:
---
$mc = new MyClass;
class MyClass {
function MyClass() {
$odbc = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\);
$query = SELECT * FROM invoice;
$result = $odbc-query($query);
die(happy);
}
}
Expected result:
It should not crash when returning the result, or when running from
within a class.
Actual result:
--
[EMAIL PROTECTED]() + 0xb
odbc32.dll!CCriticalSection::Enter() + 0xf
[EMAIL PROTECTED]() + 0xf
[EMAIL PROTECTED]() + 0x23
[EMAIL PROTECTED]() + 0x2b
php_pdo_odbc.dll!odbc_stmt_dtor(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 56C
php_pdo.dll!free_statement(_pdo_stmt_t * stmt=0x00720448, void * * *
tsrm_ls=0x00323eb0) Line 2118 + 0x8C
php_pdo.dll!php_pdo_stmt_delref(_pdo_stmt_t * stmt=0x00720448, void *
* * tsrm_ls=0x00323eb0) Line 2157 + 0xbC
php_pdo.dll!pdo_dbstmt_free_storage(_pdo_stmt_t * stmt=0x00720448,
void * * * tsrm_ls=0x00323eb0) Line 2162 + 0xf C
php5ts.dll!zend_objects_store_free_object_storage(_zend_objects_store
* objects=0x00328dc4, void * * * tsrm_ls=0x00323eb0) Line 83 + 0xb C
php5ts.dll!shutdown_executor(void * * * tsrm_ls=0x00a232c0) Line 273
+ 0x13 C
[EMAIL PROTECTED]() + 0x26
Unhandled exception at 0x7c901010 (ntdll.dll) in php-cgi.exe:
0xC005: Access violation reading location 0x0018.
--
Edit this bug report at http://bugs.php.net/?id=35620edit=1
#35552 [Asn-Fbk]: access violation on any invalid odbc query
ID: 35552
Updated by: [EMAIL PROTECTED]
Reported By: humbads at alum dot mit dot edu
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2005-12-05 (snap)
Assigned To: wez
New Comment:
I made an adjustment to the way that we pull out the error information;
I'm not sure that it will have resolved this particular issue, but it's
worth trying it out while you're checking to see if #35620 is fixed.
Previous Comments:
[2005-12-05 18:54:18] humbads at alum dot mit dot edu
This is with the latest snapshot release:
php5.1-win32-200512051530.zip
Here is the stack trace:
[EMAIL PROTECTED]() + 0x6a
[EMAIL PROTECTED]() + 0x120
[EMAIL PROTECTED]() + 0xaa
php_pdo_odbc.dll!pdo_odbc_error(_pdo_dbh_t * dbh=0x0071e6c8,
_pdo_stmt_t * stmt=0x0071ebb8, void * statement=0x, char *
what=0x005f3194, const char * file=0x005f31cc, int line=175, void * * *
tsrm_ls=0x00323f68) Line 82C
php_pdo_odbc.dll!odbc_handle_preparer(_pdo_dbh_t * dbh=0x0071e6c8,
const char * sql=0x0071e878, long sql_len=13, _pdo_stmt_t *
stmt=0x0071ebb8, _zval_struct * driver_options=0x, void * * *
tsrm_ls=0x00323f68) Line 175 + 0x20C
php_pdo.dll!zif_PDO_query(int ht=1, _zval_struct *
return_value=0x0071e808, _zval_struct * * return_value_ptr=0x,
_zval_struct * this_ptr=0x0071e878, int return_value_used=0, void * * *
tsrm_ls=0x000d) Line 992 + 0x2fC
php5ts.dll!zend_do_fcall_common_helper_SPEC(_zend_execute_data *
execute_data=0x0012fb38, void * * * tsrm_ls=0x00323f68) Line 192 +
0x35C
php5ts.dll!ZEND_DO_FCALL_BY_NAME_SPEC_HANDLER(_zend_execute_data *
execute_data=0x0012fb38, void * * * tsrm_ls=0x00323f68) Line 314 +
0x11C
php5ts.dll!execute(_zend_op_array * op_array=0x0032, void * * *
tsrm_ls=0x0071dda0) Line 92 + 0xc C
[EMAIL PROTECTED]() + 0x130
[EMAIL PROTECTED]() + 0xc
[EMAIL PROTECTED]() + 0x8a
Unhandled exception at 0x7c80a258 (kernel32.dll) in php-cgi.exe:
0xC005: Access violation writing location 0x000c.
[2005-12-05 06:15:31] humbads at alum dot mit dot edu
Description:
PHP crashes with a memory exception when running any query with invalid
syntax. The driver is PDO-ODBC-Visual Foxpro on Windows XP SP2. The
folder has full control permission for IUSR to the directory containing
the Foxpro DBF files.
The exception dialog shows:
php-cgi.exe - Application Error
The instruction at 0x7c80a258 reference memory at 0x000c. The
memory could not be written.
Using the out-of-the box install of PHP 5.1.1 with pdo and pdo_odbc
extensions loaded via php.ini. Latest Visual Foxpro ODBC driver was
downloaded from Microsoft website.
Reproduce code:
---
?php
$db = new PDO(odbc:Driver={Microsoft Visual FoxPro
Driver};SourceType=DBF;SourceDB=C:\\temp\\;Exclusive=No);
$db-query(any query with invalid syntax);
?
Expected result:
Should give a proper error message, no?
--
Edit this bug report at http://bugs.php.net/?id=35552edit=1
#35592 [Fbk]: ODBC/DB2 driver crashes Apache on bad request
ID: 35592
Updated by: [EMAIL PROTECTED]
Reported By: mrethers at ebcubes dot com
Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.1.1
Assigned To: wez
New Comment:
I couldn't reproduce the issue, but by working with Dan, did manage to
get a couple of backtraces that highlighted some code that might cause
something like this to happen.
Please try the next snapshot dated after this message to see if that
nailed it.
Previous Comments:
[2005-12-12 22:49:23] [EMAIL PROTECTED]
Confirmed the problem here with php5-win32-200512111930.zip from
snaps.php.net, as well as php-5.1.1 Windows binary from php.net,
running PHP CLI (taking Apache out of the equation).
This is with DB2 V8 FixPak 10, using the DB2 sample database cataloged
as a SYSTEM ODBC data source.
Windows XP SP1 with all current (non SP2) fixes.
My slight variation: SELECT * FROM EMPLOYEE works as expected, but
SELECT * FROM FOO.EMPLOYEE (non-existent schema) causes Windows to pop
up one of those handy little CLI has encountered a problem and needs
to close. Would you like to send this error report to microsoft?
dialogs.
I would expect an error message like the following:
SQL0204N FOO.EMPLOYEE is an undefined name. SQLSTATE=42704
[2005-12-09 05:21:27] [EMAIL PROTECTED]
Can you reproduce this with mssql or access?
[2005-12-08 22:42:52] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-12-08 17:09:17] mrethers at ebcubes dot com
I tried downloading the last snapshot for win32 but it now completely
crashes my applcation. The XML DOM extension seems to be the issue
# Suspected Code
$doc = new DOMDocument;
$doc-Load(CONFIG_PATH);
if (!$doc-validate()) {
throw new Exception(Mapping file is not valid);
}
Also I still have the DB2/ODBC problem :
# Problematic code example
try {
$dbh = new PDO('odbc:TEST', 'user', 'password');
} catch (Exception $e) {
echo Failed: . $e-getMessage();
}
$stmt = $dbh-query(SELECT * FROM Table1);
$stmt-setFetchMode(PDO::FETCH_ASSOC);
$rs = $stmt-fetchAll();
echo count($rs) . : ;
when correct query should be SELECT * FROM SCHEMA1.Table1
crashes Apache before $stmt-setFetchMode(PDO::FETCH_ASSOC);
[2005-12-08 11:26:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/35592
--
Edit this bug report at http://bugs.php.net/?id=35592edit=1
#35592 [Asn-Fbk]: ODBC/DB2 driver crashes Apache on bad request
ID: 35592
Updated by: [EMAIL PROTECTED]
Reported By: mrethers at ebcubes dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5.1.1
Assigned To: wez
New Comment:
Can you reproduce this with mssql or access?
Previous Comments:
[2005-12-08 22:42:52] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-12-08 17:09:17] mrethers at ebcubes dot com
I tried downloading the last snapshot for win32 but it now completely
crashes my applcation. The XML DOM extension seems to be the issue
# Suspected Code
$doc = new DOMDocument;
$doc-Load(CONFIG_PATH);
if (!$doc-validate()) {
throw new Exception(Mapping file is not valid);
}
Also I still have the DB2/ODBC problem :
# Problematic code example
try {
$dbh = new PDO('odbc:TEST', 'user', 'password');
} catch (Exception $e) {
echo Failed: . $e-getMessage();
}
$stmt = $dbh-query(SELECT * FROM Table1);
$stmt-setFetchMode(PDO::FETCH_ASSOC);
$rs = $stmt-fetchAll();
echo count($rs) . : ;
when correct query should be SELECT * FROM SCHEMA1.Table1
crashes Apache before $stmt-setFetchMode(PDO::FETCH_ASSOC);
[2005-12-08 11:26:51] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.1-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.1-win32-latest.zip
[2005-12-08 00:05:28] mrethers at ebcubes dot com
Description:
I'm using a db2 database with pdo:odbc and some bad queries would crash
Apache. It's a major problem for debugging as I have to verify all the
requests with a SQL command line tool.
Reproduce code:
---
SELECT * FROM TableA, TableB;
where TableA and TableB are in schema SCHEMA_1
The acutal query should be:
SELECT * FROM SCHEMA_1.TableA, SCHEMA_2.TableB;
Expected result:
SQL Exception from error thrown by the database
Actual result:
--
Apache crashes
--
Edit this bug report at http://bugs.php.net/?id=35592edit=1
#35607 [Asn-Fbk]: Apache 2.0 Crash with Update command
ID: 35607
Updated by: [EMAIL PROTECTED]
Reported By: wseibert at hxcorp dot com
-Status: Assigned
+Status: Feedback
Bug Type: PDO related
Operating System: Windows 2k
PHP Version: 5CVS-2005-12-08 (snap)
Assigned To: wez
New Comment:
Can you provide a CREATE TABLE statement or a small copy of your actual
.mdb file, so that I can test against the same schema you're using?
Previous Comments:
[2005-12-08 21:34:46] [EMAIL PROTECTED]
Assigned to the maintainer.
[2005-12-08 21:12:16] wseibert at hxcorp dot com
Sorry, I know this is going to be difficult to duplicate as I'm
connecting to a Access DB on my local machine via ODBC. If you have a
Access DB on your system, you just need to set it up in your ODBC
Manager and point to that DSN in the script. Once that is done, try
doing a Update SQL command via PDO::query, Then try it via PDO::exec.
If it works (correctly), it should return the number of rows affected.
It crashes for me on the query, and does nothing on the exec.
[2005-12-08 21:07:57] wseibert at hxcorp dot com
?php
try
{
$dbh = new PDO('odbc:DSN=TEST;driver=Driver do Microsoft Access
(*.mdb)','','');
$results = $dbh-query('UPDATE xd17 SET xd17.CCDate = 20051207,
xd17.CCTime = 1200, xd17.ModifiedDS = 200512071200 WHERE xd17.XTyp17 =
157 AND xd17.X15A = 51921 AND xd157.X105B = 3300');
} catch (PDOException $e) {
print Error!: .$e-getMessage().br/;
die();
}
?
[2005-12-08 20:58:56] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves.
A proper reproducing script starts with ?php and ends with ?,
is max. 10-20 lines long and does not require any external
resources such as databases, etc.
If possible, make the script source available online and provide
an URL to it here. Try to avoid embedding huge scripts into the report.
[2005-12-08 20:49:06] wseibert at hxcorp dot com
Description:
Running a UPDATE sql command via PDO crashes Apache.
Reproduce code:
---
try
{
$dbh = new PDO('odbc:DSN=TEST;driver=Driver do Microsoft Access
(*.mdb)','','');
$results = $dbh-query('UPDATE xd17 SET xd17.CCDate = 20051207,
xd17.CCTime = 1200, xd17.ModifiedDS = 200512071200 WHERE xd17.XTyp17 =
157 AND xd17.X15A = 51921 AND xd157.X105B = 3300');
} catch (PDOException $e) {
print Error!: .$e-getMessage().br/;
die();
}
Expected result:
Expected to see changes in DB.
Using exec ($dbh-exec() ) instead of query has no effect. Doesn't
update the DB or crash anything.
SQL statement works find in MS Access.
Actual result:
--
Apache.exe - Application Error
The instruction at 0x7c5b97d4 referenced memory at 0x000c. The
memory could no be written.
--
Edit this bug report at http://bugs.php.net/?id=35607edit=1
