Bug #64852 [Asn]: Allow binding arrays in PDO
Edit report at https://bugs.php.net/bug.php?id=64852&edit=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: 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: 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: 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: 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=64852&edit=1
Bug #63347 [Asn->Nab]: Different behavior of parameters processing
Edit report at https://bugs.php.net/bug.php?id=63347&edit=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: --- 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=63347&edit=1
Bug #53458 [Opn]: Non-linear performance degradation on certain prepared SELECT queries
Edit report at http://bugs.php.net/bug.php?id=53458&edit=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=53458&edit=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=48061&edit=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: --- 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=47984&edit=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=27792&edit=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: --- 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=42036&edit=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=41135&edit=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=41135&edit=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=40543&edit=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 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 , 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=40289&edit=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=40848&edit=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
#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 0x"80020003" , 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 ".." 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-bug2>bug2-test1.php TEST #1 OK! D:\php-bug2>bug2-test2.php TEST #2 OK! D:\php-bug2>bug2-test3.php TEST #3 OK! D:\php-bug2>bug2-test4.php TEST #4 OK! D:\php-bug2>bug2-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-bug2>bug2-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 --- 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 --- This works fine $word = new COM('Word.Application') or die('Start Word
#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=39822&edit=1
#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 # include # 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=39224&edit=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 th
#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: --- 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=38488&edit=1
#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 -
#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: On shutdown both $s and STDIN constant are destroyed, but they both poin
#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()) . ""; // $stmt = null; $stmt2 = $dbh->prepare("exec pdo_test"); $stmt2->execute(); echo $x . " " . var_dump($stmt2->fetch()) . ""; 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=39141&edit=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=39161&edit=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 /* * 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 /* * 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 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=39130&edit=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) "$2,500$4,999 2 x 4, Inc Alan Brasington Network Eleanor S. Applewhaite Martha and Thomas G. Armstrong Jody and John Arnhold Page Ashley In Memory of Betty L. Asiel Rosalind Case Avrett Susan Baker and Michael Lynch Lucy and Joel Banker Dave Barger Richard and Eslyn Bassuk Ginette and Joshua Becker Margaret and James Bernstein Leslie and George C. Biddle Marilyn Friedman and Thomas Block Harvi and Bob Bloom The Blythmour Corporation Brian R. Meara Public Relations Inc. The Brodsky Organization David Brown and Helen Gurley Brown Marian Culbertson Hvolbeck Mr. and Mrs. Willard C. Butcher Frank and Nancy Bynum Ms. Deborah Carmichael John K. Castle Elizabeth and Jay Chandler Mr. and Mrs. Michael J. Chasanoff Citigroup Private Bank Connie and Richard W. Cohen Colgate-Palmolive Company Con Edison Peter and Julie Cummings Ms. Marjorie M. Curry Matthew J. Cvetic D. Ronald Daniel and Lise Scott Lucy and Mike Danziger Mr. and Mrs. J. Dennis Delafield Jamie deRoy Gayle and Dan Devin Valerie and Charles Diker Robert and Marti Dinerstein Discovery Communications, Inc. DMJM Harris Anthony Dolce Ms. Domitilia M. dos Santos In Memoriam - Mr. and Mrs. Gerald A. Dundon Edison Properties, LLC Edmar Lewis and Judy Eisenberg Nancy Donohue and Diane Elam Empire BlueCross BlueShield Paula S. Epsteen Stanley Epstein Mr. and Mrs. Leroy Fadem Roger N. Farah/Polo Ralph Lauren Foundation Fiona Morgan Fein Mr. and Mrs. Massimo Ferragamo Arlene and Robert Fischer Andrew Frackman and Emily Braun Juliet Frank Freedom Forum Cynthia and Eliot Fried The Barry Friedberg and Charlotte Moss Family Foundation Patrice and Louis Friedman In Memory of Ella and George Geiger Ms. Lynn Gilbert Mr. & Mrs. Richard F. Goodman Ms. Beth S. Gould Mr. and Mrs. Harry E. Gould, Jr. Gray Family Foundation Annette Green Mr. and Mrs. Maurice R. Greenberg/The Greenberg Foundation Naava and Sanford Grossman Doris Grzymski Ralph and Calla Guild Mr. and Mrs. John H. Gutfreund Gerry Harper Mary W. Harriman Foundation Ted & Dina Merrill Hartley Mrs. Eva Hartman Linda and Mel Heineman Marian S. Heiskell David M. Helpern Buck Henry Charitable Fund Administered by the California Community Foundation John S. Herold, Inc. Ellen and David S. Hirsch Jacqueline and Robert Hochberg Will Holt Carol and Howard Holtzmann Ruth W. Houghton Mr. and Mrs. Charles O. Hoyt Jill and Ken Iscol Dr. and Mrs. Julius H. Jacobson II Linda and Morton Janklow Freda S. Johnson Marnee and Eric Kaltman The Kandell Fund Maury I. Kaplin Mr. and Mrs. John A. Kauffmann Stuart and Isabel Kessler Dr. Herry Kijner Kirkland & Ellis LLP Victor and Sarah Kovner Alice and Dennis Krieger Linda L. and
#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: --- 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=38458&edit=1
#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=) 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=38054&edit=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 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 ""; print_r($e); echo ""; } ?> [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 , 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=39052&edit=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=38985&edit=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=38985&edit=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=38805&edit=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=30157&edit=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: --- 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=30157&edit=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=38182&edit=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=38103&edit=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=37319&edit=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=37497&edit=1
#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=37361&edit=1
#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 `mysql_re
#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 functio
#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=35272&edit=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=37037&edit=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=36449&edit=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 .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=37097&edit=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=36752&edit=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[]: <>: 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[]: <>: 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=36632&edit=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 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=36449&edit=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: --- 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=36228&edit=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=35793&edit=1
#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=35793&edit=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
#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=36128&edit=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$►Wï=♦A☺☺Vhli☺☺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 Warning: PHP Startup: SVït$►Wï=♦A☺☺Vhli☺☺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 PHP Warning: PHP Startup: Φ;╚: 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 Warning: PHP Startup: Φ;╚: 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 -- Edit this bug report at http://bugs.php.net/?id=37227&edit=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=37158&edit=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=37158&edit=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: --- 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=37158&edit=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 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); 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=35386&edit=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=36752&edit=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[]: <>: 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[]: <>: 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=36632&edit=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 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().""; 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=35607&edit=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 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: 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 = ''; $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 , 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=37124&edit=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 .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=37097&edit=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 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 . ''; $indent++; /* To reproduce error, comment out $test definition then replace $test in foreach loop with $section->childSections */ $test = $section->childSections; foreach($test as $childSection) { buildSectionRow($childSection, $indent); } } ?> [2006-04-09 07:44:21] [EMAIL PROTECTED] Please paste the script into the bug report. I can't reach the URL you posted. [2006-0
#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=36402&edit=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: --- 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=36662&edit=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: --- 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=1143141&r=1&w=2 -- Edit this bug report at http://bugs.php.net/?id=36890&edit=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=36681&edit=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: --- 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=36652&edit=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=36602&edit=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: 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=36561&edit=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 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=36449&edit=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 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=36402&edit=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
#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 , 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=36143&edit=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=36128&edit=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: --- 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=35935&edit=1
#35919 [Asn->Fbk]: Bad substitution with PDO::prepare
ID: 35919 Updated by: [EMAIL PROTECTED] Reported By: atixier at france-loisirs dot com -Status: Assigned +Status: Feedback Bug Type: PDO related Operating System: AIX 4.3.3 PHP Version: 5CVS-2006-01-06 (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-01-19 11:57:11] tommys at da2 dot so-net dot ne dot jp PHP 5.1.2 with Oracle 10gR1: $id = 123; $name = 'foo'; $stmt = $dbh->prepare("select ?,? from dual"); $stmt->execute(array($id, $name)); while ($row = $stmt->fetch(PDO::FETCH_ASSOC)) { print_r($row); } Output: Array ( [:PDO1] => foo [:PDO2] => foo ) With bindValue(): $stmt->bindValue(1, $id); $stmt->bindValue(2, $name); $stmt->execute(); is same result. With named placeholders: $stmt = $dbh->prepare("select :id, :name from dual"); $stmt->bindValue(':id', $id); $stmt->bindValue(':name', $name); $stmt->execute(); Output: Array ( [:ID] => foo [:NAME] => foo ) With bindParam(): $stmt = $dbh->prepare("select :id, :name from dual"); $stmt->bindParam(':id', $id); $stmt->bindParam(':name', $name); $stmt->execute(); Array ( [:ID] => -1.990921021434 [:NAME] => -1.990921021434 ) [2006-01-06 16:17:28] atixier at france-loisirs dot com Description: I'm testing PDO with Oracle 9iR2. Evrything is OK, but I experience two problems whith PDO:Prepare when using question mark or names parameters. Whith this sequence: $stmt=$dbh->prepare("insert into R_QQQ (QUANTIEME,RUN) values (?,?)"); $stmt->execute(array("ZYX", "053")); $stmt=$dbh->query("select * from R_QQQ"); $rows=$stmt->fetchAll(PDO::FETCH_ASSOC); foreach ($rows as $row) { print("\n"); print_r($row); print("\n"); } I get the following result: Array ( [RUN] => 053 [DH_FIN] => 06-JAN-06 [QUANTIEME] => 053 ) Second bug: when I try to insert a date whith the following command: $stmt=$dbh->prepare("insert into R_QQQ (QUANTIEME,DH_FIN,RUN) values (?,?,?)"); $stmt->execute(array("ZYX", "to_date('20050222','MMDD')","053")); I get an error ORA-01861: SQLSTATE[HY000]: General error: 1861 OCIStmtExecute: ORA-01861: literal does not match format string (/prod/outils/php5.1-200601051130/ext/pdo_oci/oci_statement.c:142) Everyting is OK when using directly: PDO:exec ("insert ..."); Thank you for your help. Expected result: Array ( [RUN] => ZYX [DH_FIN] => 22-FEB-05 [QUANTIEME] => 053 ) Actual result: -- Array ( [RUN] => 053 [DH_FIN] => 06-JAN-06 [QUANTIEME] => 053 ) -- Edit this bug report at http://bugs.php.net/?id=35919&edit=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=35910&edit=1
#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=35830&edit=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: 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." setAttribute(PDO::ATTR_ERRMODE,PDO::ERRMODE_EXCEPTION); $result = $db->query('SELECT COUNT(*) FROM Locations'); echo $result.""; $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.""; $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: 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 . "
#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 ""; print_r( $row );echo ""; } 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=36342&edit=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-db&m=114014376609292&w=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=35671&edit=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 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); 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 ''.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=35386&edit=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 ""; print_r( $row );echo ""; } 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=36342&edit=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: --- 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=36492&edit=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=36344&edit=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=36281&edit=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: --- 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=26495&edit=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=35793&edit=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: 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 ''; } $result = Query(); foreach ($result as $day) { print_r($day); echo ''; } $result = Query(); foreach ($result as $day) { print_r($day); echo ''; } ?> 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=35793&edit=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=35795&edit=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=35795&edit=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] 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=35770&edit=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=35756&edit=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: --- com_event_sink test page \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!"); ?> 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=35719&edit=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: --- "; } ?> 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=35689&edit=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=35592&edit=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: --- 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=35552&edit=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=35620&edit=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=35620&edit=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 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().""; 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 , 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().""; 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=35607&edit=1