#43246 [Opn-Csd]: firebird: INSERT ... RETURNING ... throws exception
ID: 43246
Updated by: [EMAIL PROTECTED]
Reported By: hp-php dot net at oeri dot ch
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: Linux 2.6
PHP Version: 5.3CVS-2007-11-11 (CVS)
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 PHP_5_3
Previous Comments:
[2007-11-15 21:08:54] hp at oeri dot ch
There seems to be no possibility to differentiate singleton queries
from recordset (execute procedure can return recordsets, no?).
The best solution - conforming to docs - is:
http://php.pastebin.com/f748ad795
Specification:
a) everything returns only by fetch
b) procedure can only fetch one row
c) fetch on something else than select/procedure does not
segfault
[2007-11-15 18:48:54] hp at oeri dot ch
Path against the latest CVS version:
http://php.pastebin.com/f4184b130
[2007-11-12 16:05:55] hp-php dot net at oeri dot ch
Although I'm not a C master, I've looked through the code and found:
pdo_statement.c:
/* an EXECUTE PROCEDURE statement can be fetched from once, without
calling the API, because
* the result was returned in the execute call */
That's totally contrary to the docs and source of this bug. As it is,
RETURNING querys get classified as procedures. Cleaning
pdo_statement.c of this special behaviour, solves the bug! Below, you
find a minimally intrusive patch (as I don't know how to attach in
here):
diff -u php5-orig/ext/pdo_firebird/firebird_statement.c
php5/ext/pdo_firebird/firebird_statement.c
--- php5-orig/ext/pdo_firebird/firebird_statement.c 2007-11-12
16:59:34.0 +0100
+++ php5/ext/pdo_firebird/firebird_statement.c 2007-11-12
16:58:46.0 +0100
@@ -99,11 +99,15 @@
/* assume all params have been bound */
+#if 0
if ((S-statement_type ==
isc_info_sql_stmt_exec_procedure
isc_dsql_execute2(H-isc_status,
H-tr, S-stmt, PDO_FB_SQLDA_VERSION,
S-in_sqlda, S-out_sqlda))
|| isc_dsql_execute(H-isc_status,
H-tr, S-stmt, PDO_FB_SQLDA_VERSION,
S-in_sqlda)) {
+#else
+ if (isc_dsql_execute(H-isc_status, H-tr, S-stmt,
PDO_FB_SQLDA_VERSION, S-in_sqlda)) {
+#endif
break;
}
@@ -138,9 +142,11 @@
/* an EXECUTE PROCEDURE statement can be fetched from
once, without calling the API, because
* the result was returned in the execute call */
+#if 0
if (S-statement_type ==
isc_info_sql_stmt_exec_procedure) {
S-exhausted = 1;
} else {
+#endif
if (isc_dsql_fetch(H-isc_status, S-stmt,
PDO_FB_SQLDA_VERSION, S-out_sqlda)) {
if (H-isc_status[0]
H-isc_status[1]) {
RECORD_ERROR(stmt);
@@ -148,7 +154,9 @@
S-exhausted = 1;
return 0;
}
+#if 0
}
+#endif
return 1;
}
return 0;
[2007-11-12 12:49:36] hp-php dot net at oeri dot ch
INSERT ... RETURNING works fine with pdo_pgsql. An indice for a
problem within pdo_firebird (and not pdo itself).
[2007-11-11 14:24:59] hp-php dot net at oeri dot ch
Description:
Executing (prepared or directly) an INSERT ... RETURNING throws an
exception
Reproduce code:
---
?php
$pdo = new PDO( 'firebird:dbname=localhost:devel', 'devel', 'devel' );
$pdo-setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION );
// VARIANT A: ORDINARY INSERT
$stmt = $pdo-query( 'INSERT INTO a (data) VALUES (2500)' );
echo Variant 'A': done;
// VARIANT B: RETURNING INSERT
$stmt = $pdo-query( 'INSERT INTO a (data) VALUES (2500) RETURNING
data' );
$res = $stmt-fetchAll( PDO::FETCH_ASSOC );
print_r( $res );
echo Variant 'B': done;
?
Expected result:
Variant 'A': done
Variant 'B': done
(Both statements executed)
Actual result:
--
Variant 'A': donebr /
bFatal error/b: Uncaught exception 'PDOException' with message
'SQLSTATE[HY000]: General error: -804 Dynamic SQL Error SQL error code =
-804 Incorrect values within SQLDA structure ' in PHPDocument4:11
Stack trace:
#0 PHPDocument4(11): PDO-gt;query('INSERT INTO
#43271 [Opn-Csd]: firebird: closeCursor not implemented
ID: 43271
Updated by: [EMAIL PROTECTED]
Reported By: hp-php dot net at oeri dot ch
-Status: Open
+Status: Closed
Bug Type: PDO related
Operating System: Linux 2.6
PHP Version: 5.3CVS-2007-11-12 (CVS)
Assigned To: lwe
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-11-15 08:52:40] hp-php dot net at oeri dot ch
The patch is/was faulty. To regain compileability:
diff -r1.18.2.1.2.5.2.6 firebird_statement.c
633c633
if ((*S-name || S-cursor_open)
isc_dsql_free_statement(H-isc_status, S-stmt, DSQL_close)) {
---
if ((*S-name || S-cursor_open)
isc_dsql_free_statement(S-H-isc_status, S-stmt, DSQL_close)) {
[2007-11-14 22:19:19] [EMAIL PROTECTED]
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.
Actually there was a bug in execute(), which didn't close an open
cursor before attempting to execute the second time. This bug is fixed,
so it is now possible to make repeated calls to execute on one prepared
statement.
But added closecursor() anyway as it wouldn't do any harm, and it does
make sense, if one uses named cursors (set by set_attribute())
Fixed in PHP_5_3 branch.
/Lars
[2007-11-13 18:15:47] [EMAIL PROTECTED]
Lars, you recently spent some time on firebird issues, can you review
this report?
[2007-11-12 21:13:07] hp-php dot net at oeri dot ch
Description:
It seems that PDOStatement-closeCursor is not implemented for
pdo_firebird. I'm unable to re-use prepared statements...
I tried to implement a minimalistic version:
http://php.pastebin.com/f476261f8
--
Edit this bug report at http://bugs.php.net/?id=43271edit=1
#43271 [Asn-Csd]: firebird: closeCursor not implemented
ID: 43271 Updated by: [EMAIL PROTECTED] Reported By: hp-php dot net at oeri dot ch -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: Linux 2.6 PHP Version: 5.3CVS-2007-11-12 (CVS) Assigned To: lwe 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. Actually there was a bug in execute(), which didn't close an open cursor before attempting to execute the second time. This bug is fixed, so it is now possible to make repeated calls to execute on one prepared statement. But added closecursor() anyway as it wouldn't do any harm, and it does make sense, if one uses named cursors (set by set_attribute()) Fixed in PHP_5_3 branch. /Lars Previous Comments: [2007-11-13 18:15:47] [EMAIL PROTECTED] Lars, you recently spent some time on firebird issues, can you review this report? [2007-11-12 21:13:07] hp-php dot net at oeri dot ch Description: It seems that PDOStatement-closeCursor is not implemented for pdo_firebird. I'm unable to re-use prepared statements... I tried to implement a minimalistic version: http://php.pastebin.com/f476261f8 -- Edit this bug report at http://bugs.php.net/?id=43271edit=1
#43296 [Opn-Csd]: firebird: ATTR_FETCH_TABLE_NAMES support
ID: 43296 Updated by: [EMAIL PROTECTED] Reported By: hp-php dot net at oeri dot ch -Status: Open +Status: Closed Bug Type: PDO related Operating System: Linux 2.6 PHP Version: 5.3CVS-2007-11-14 (CVS) 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. Implemented the suggestion almost as is. Fixed in PHP_5_3 Previous Comments: [2007-11-14 15:00:48] hp-php dot net at oeri dot ch Description: pdo_firebird NOT supporting ATTR_FETCH_TABLE_NAMES when the library easily supports it might be a bug or subject of a feature request (which I don't know where to place). Let me humbly suggest a patch I posted today on php.internals: news://news.php.net/[EMAIL PROTECTED] -- Edit this bug report at http://bugs.php.net/?id=43296edit=1
#43244 [Opn-Csd]: firebird: closeCursor w/o returned data kills process
ID: 43244 Updated by: [EMAIL PROTECTED] Reported By: hp-php dot net at oeri dot ch -Status: Open +Status: Closed Bug Type: PDO related Operating System: Linux 2.6 PHP Version: 5.3CVS-2007-11-11 (CVS) 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. Now repeated calls to closecursor() won't cause a crash. Fixed in PHP_5_3 Previous Comments: [2007-11-11 12:54:30] hp-php dot net at oeri dot ch Description: In pdo_firebird from CVS, calling PDOStatement-closeCursor on an executed statement that did *NOT* return any data kills the process. Reproduce code: --- ?php $pdo = new PDO( 'firebird:dbname=localhost:devel', 'devel', 'devel' ); // VARIANT A: SECONDARY DATA $stmt = $pdo-prepare( 'UPDATE a_data SET data=200 RETURNING a' ); $stmt-execute(); // the following statement works fine $stmt-closeCursor(); echo I survived variant 'A'\n; // VARIANT B: REALLY NO DATA $stmt = $pdo-prepare( 'UPDATE a_data SET data=200' ); $stmt-execute(); // the following statement kills the process $stmt-closeCursor(); echo I don't survive upto here...\n; ? Expected result: I survived variant 'A' I don't survive upto here... (Both statements executed an closeCursor called twice) Actual result: -- I survived variant 'A' (Variant 'B' - the non-data statement - kills the process before echo.) -- Edit this bug report at http://bugs.php.net/?id=43244edit=1
#30907 [Asn-Csd]: ibase_query() crashes when inserting a -1 into a Interbase TIMESTAMP field
ID: 30907 Updated by: [EMAIL PROTECTED] Reported By: sandell at winwap dot com -Status: Assigned +Status: Closed Bug Type: InterBase related Operating System: WinXP Pro (SP2) PHP Version: 5CVS-2005-03-01 Assigned To: abies 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 HEAD and PHP_5_3 Previous Comments: [2007-10-23 17:21:44] Lars dot Westermann at privat dot dk This bug is in fact the same as #32143 Look at the first param to ibase_query(). This is *not* the resource returned from ibase_connect(). The empty parameter is then passed as an empty querystring (as it is not a resource, it is treated as a (query)string). This empty querystring crashes IBserver 7 (but not Firebird 2). A possible bugfix is suggested, and hopefully a bugfix is on it's way (in PHP 5.3). [2005-03-01 09:01:05] sandell at winwap dot com The new Snapshot (downloaded 1.3.2005) still causes Apache to crash. Tested with: - Interbase Server v7.1 (WI-V7.1.0.192). - Apache 2.0.50 - PHP 5.1.0-DEV [2005-02-28 21:22:17] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5-latest.tar.gz For Windows: http://snaps.php.net/win32/php5-win32-latest.zip [2005-02-24 10:20:36] sandell at winwap dot com Compiling stuff is out of scope for me, sorry. The compiling must be done by someone else who knows how to do it. [2005-02-24 10:12:23] [EMAIL PROTECTED] Please try if the error can be reproduced with a php_interbase.dll built from source using the ibase.h header file that comes with Interbase 7.1 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/30907 -- Edit this bug report at http://bugs.php.net/?id=30907edit=1
#39056 [NoF-Csd]: Interbase NUMERIC data type error
ID: 39056
Updated by: [EMAIL PROTECTED]
Reported By: ddi at elecom dot ru
-Status: No Feedback
+Status: Closed
Bug Type: InterBase related
Operating System: All
PHP Version: 5.1.6
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 HEAD and PHP_5_3
Previous Comments:
[2006-10-14 01:00:00] 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-10-06 06:50:22] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to Open.
Thank you for your interest in PHP.
[2006-10-06 06:26:52] ddi at elecom dot ru
Description:
The _php_ibase_var_zval function of ibase_query.c has error:
static ISC_INT64 const scales[] = { 1, 10, 100, 1000,
1,
10,
100,
1,
10,
10, LL_LIT
(100),LL_LIT
(1000),LL_LIT
(10),LL_LIT
(100),LL_LIT
(1000),LL_LIT
(1000),LL_LIT
(100) };
Must be
static ISC_INT64 const scales[] = { 1, 10, 100, 1000,
1,
10,
100,
1000,
1,
10, LL_LIT
(100),LL_LIT
(1000),LL_LIT
(1),LL_LIT
(10),LL_LIT
(100),LL_LIT
(1000),LL_LIT
(1) };
--
Edit this bug report at http://bugs.php.net/?id=39056edit=1
#39700 [Opn-Csd]: NUMERIC error when result precision are 7,8 or 12-14
ID: 39700
Updated by: [EMAIL PROTECTED]
Reported By: ilpochta at gmail dot com
-Status: Open
+Status: Closed
Bug Type: InterBase related
Operating System: All
PHP Version: 5.2.0
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 HEAD and PHP_5_3
Previous Comments:
[2007-09-11 10:44:28] nb,b at fdhf dot hgk
http://www.meta-fx.com/
[2007-01-22 10:34:18] [EMAIL PROTECTED]
Are the php_interbase maintained?
No, feel free to take it over.
[2007-01-22 10:29:36] ilpochta at gmail dot com
Are the php_interbase maintained?
Please, fix this bug before PHP-5.2.1. Just recount the nulls in
scales array :)
[2006-12-01 21:51:52] ilpochta at gmail dot com
Take the solution from #39056, add two strings to them (for precisions
17 and 18) and it works! :)
# diff ./php-5.2.0/ext/interbase/old/ibase_query.c
./fixed/ext/interbase/ibase_query.c
1289,1291c1289,1304
static ISC_INT64 const scales[] = { 1, 10, 100, 1000, 1,
10, 100, 1, 10,
10,
LL_LIT(100),LL_LIT(1000),LL_LIT(10),LL_LIT(100),
LL_LIT(1000),LL_LIT(1000),LL_LIT(100)
};
---
static ISC_INT64 const scales[] = { 1, 10, 100, 1000,
1,
10,
100,
1000,
1,
10, LL_LIT
(100),LL_LIT
(1000),LL_LIT
(1),LL_LIT
(10),LL_LIT
(100),LL_LIT
(1000),LL_LIT
(1),LL_LIT
(10),LL_LIT
(100) };
--
I think, same error is present in function firebird_stmt_get_col() from
ext/pdo_firebird/firebird_statement.c .
[2006-12-01 11:09:47] [EMAIL PROTECTED]
You can try to change the lines mentioned in #39056 (see
ext/interbase/ibase_query.c) and tell us if it works.
I don't think anybody here uses Interbase these days.
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/39700
--
Edit this bug report at http://bugs.php.net/?id=39700edit=1
#42284 [Opn-Csd]: Invalid data retrieved from numeric columns
ID: 42284
Updated by: [EMAIL PROTECTED]
Reported By: milan dot babuskov at gmail dot com
-Status: Open
+Status: Closed
Bug Type: InterBase related
Operating System: Slackware Linux 12.0
PHP Version: 5.2.4RC1
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-10-21 16:11:57] ilpochta at gmail dot com
Duplicate of the http://bugs.php.net/39700
This bug is dangerous, because you may get incorrect result when you
multiply fields with smaller precision.
E.g. for international shop:
CREATE TABLE goods (id INTEGER, price NUMERIC(10,4));
CREATE TABLE currency (code CHAR(3), exchange_rate NUMERIC(10,4));
SELECT goods.id, goods.price*currency.exchange_rate AS local_price
FROM goods, currency WHERE currency.code='EUR'
...and you lucky customers have goods for 1/10 of price :(
[2007-08-16 13:40:10] milan dot babuskov at gmail dot com
It works properly with PHP 4.x versions. The problem is in function
_php_ibase_var_zval, in the SQL_INT64 branch of the 'case' statement. If
I take the same part from PHP 4.4.0 and copy it there, everything works
properly (I also needed to add ISC_INT64_FORMAT define which was
missing).
Please note that 5.x code works properly with NUMERIC(18,5) for
example. But it fails for NUMERIC(18,7) and 18,8. I didn't test other
types, but I assume if fails for any precision greater than 6. PHP 4.x
code works properly in all cases.
[2007-08-13 13:44:46] milan dot babuskov at gmail dot com
Fields D5 and D6 should be D1 and D2. Sorry for the confusion.
[2007-08-13 13:43:06] milan dot babuskov at gmail dot com
Description:
PHP does not extract the values in NUMERIC(18,7) and NUMERIC(18,8)
columns correctly.
Reproduce code:
---
create table test ( d1 numeric(18,7), d2 numeric(18,8));
insert into test (d1,d2) values (6543210.1234567, 87654321.01234567);
commit;
?
ibase_connect('localhost:mydb','sysdba', 'aa');
$res = ibase_query('select d5, d6 from test');
$row = ibase_fetch_row($res);
echo D5 = .$row[0].,\n;
echo D6 = .$row[1].\n;
?
Expected result:
D5 = 6543210.1234567,
D6 = 87654321.01234567
Actual result:
--
D5 = 654321.1234567,
D6 = 8765432.101234567
--
Edit this bug report at http://bugs.php.net/?id=42284edit=1
#39397 [Opn-Csd]: invalid statement handle in Unknown on line 0
ID: 39397
Updated by: [EMAIL PROTECTED]
Reported By: sailormax at inbox dot lv
-Status: Open
+Status: Closed
Bug Type: InterBase related
Operating System: Win32 / Linux
PHP Version: 5.2.0
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 HEAD and PHP_5_3
Previous Comments:
[2006-11-06 10:50:46] sailormax at inbox dot lv
Description:
PHP output warning:
Warning: Unknown: invalid statement handle in Unknown on line 0
if don't use connection_id as parameter for function ibase_close()
Firebird 2.0 Release Candidate
Reproduce code:
---
?
ibase_connect(localhost:D:\\test.gdb, SYSDBA, masterkey);
$prep = ibase_prepare(SELECT * FROM TB_TEST);
$res = ibase_execute($prep);
while ($row = ibase_fetch_row($res))
{
print_r($row);
print br /;
}
ibase_close();
?
Expected result:
output list of data in table
Actual result:
--
output list of data in table
and
Warning: Unknown: invalid statement handle in Unknown on line 0
--
Edit this bug report at http://bugs.php.net/?id=39397edit=1
#32143 [Asn-Csd]: ibase_query() causes IB server crash with invalid DB and parameters
ID: 32143 Updated by: [EMAIL PROTECTED] Reported By: sandell at winwap dot com -Status: Assigned +Status: Closed Bug Type: InterBase related Operating System: Windows XP SP2 PHP Version: 5CVS-2005-03-01 Assigned To: abies 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 HEAD and PHP_5_3 Previous Comments: [2005-12-26 16:34:51] [EMAIL PROTECTED] Assigned to the maintainer. [2005-03-01 09:18:37] sandell at winwap dot com Description: ibase_query() causes a Interbase Server crash if an invalid DB handle is used and parameters are passed in the function. There must be an existing DB connection opened with ibase_connect(). System info (All on same machine): - Windows XP SP2 - Apache 2.0.50 - PHP 5.1.0-DEV (Downloaded 1.3.2005) - Interbase Server WI-V7.1.0.192 Reproduce code: --- // Crash Code $db = ibase_connect($dbname,'SYSDBA','masterkey','None',0,3); $sql = SELECT * FROM aTable WHERE Status = ?; $sth = ibase_query($db_hand, $sql, 0 ); // - THIS LINE CRASHES IB SERVER (Note $db_hand variable) ibase_close($db); Expected result: function should fail with an error reported to the log Actual result: -- Interbase Server crashes -- Edit this bug report at http://bugs.php.net/?id=32143edit=1
#30690 [Opn-Csd]: InterBase: Resource handle from ibase_execute becomes invalid after return
ID: 30690
Updated by: [EMAIL PROTECTED]
Reported By: kobaz at kobaz dot net
-Status: Open
+Status: Closed
Bug Type: Feature/Change Request
Operating System: Linux 2.6.5
PHP Version: 4.3.9
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 HEAD and PHP_5_3
Previous Comments:
[2005-02-09 20:33:59] kobaz at kobaz dot net
Er, and of course add the extra global variable, but you get the point.
[2005-02-09 20:32:36] kobaz at kobaz dot net
I have a workaround for this bug:
$PQUERY = array();
$curpquery = 0;
function DB_PQuery ($sql, $data) {
global $PQUERY, $conn;
$PQUERY[$curpquery] = ibase_prepare($conn, $sql);
$result = ibase_execute($PQUERY[$curpquery], $data);
$curpquery++;
return $result;
}
I agree with the previous poster that the result from prepare being
destroyed after it goes out of scope is very inconsistant with the rest
of the database interfaces for php and makes coding for interbase
awkward.
[2005-02-09 18:16:08] [EMAIL PROTECTED]
While this behavior may be intentional on your part, I strongly request
it be changed.
1) No other DBMS extension in PHP does this.
2) This makes writing programs using ibase very difficult.
3) This makes it impossible to write abstraction packages, such as PEAR
DB (which I'm the lead of).
[2004-11-07 14:21:36] [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
When $prepare goes out of scope, it is cleaned up along with all the
resources that depend on it. That includes any results that it created.
[2004-11-05 02:16:40] kobaz at kobaz dot net
Description:
Resource handle from ibase_execute becomes invalid after return
Reproduce code:
---
$conn = ibase_connect('localhost:db', 'SYSDBA', 'pass');
function DB_PQuery ($sql, $data) {
global $conn;
$prepare = ibase_prepare($conn, $sql);
$result = ibase_execute($prepare, $data);
//$A = ibase_fetch_assoc($result); // uncommenting this will
show resource is valid here
//print_r($A);
// after this function returns, the return value is no longer a valid
resource
return $result;
}
$result = DB_PQuery(SELECT * FROM testing WHERE a = ?, '1');
$A = ibase_fetch_assoc($result); // fails with: invalid statement
handle
print_r($A);
Expected result:
The ibase_fetch_assoc should be successful after DB_PQuery returns.
Actual result:
--
Before DB_PQuery returns, $result is a valid resource handle that can
be used with ibase_fetch_assoc successfully.
After DB_PQuery returns, the return value is not a valid resource
handle despite that nothing in the script has modified it.
--
Edit this bug report at http://bugs.php.net/?id=30690edit=1
#23613 [Opn-Bgs]: [INTERBASE] ibase_fetch_assoc() / ibase_fetch_object() elements case-sensitive
ID: 23613
Updated by: [EMAIL PROTECTED]
Reported By: vhcampos at terra dot com dot br
-Status: Open
+Status: Bogus
Bug Type: Feature/Change Request
Operating System: Windows 98
PHP Version: 4.3.2-RC3-dev
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
According to the Interbase/Firebird documentation, columns are
case-sensitive, when declared using double qoutes, as you have done in
your create table example.
And you are forced to use double qoutes around every column-name in sql
statements.
ibase_fetch_object returns case-sensitive property names.
If you declare the columns without double qoutes, the names are
case-insensitive in SQL statements (and you write them without double
quotes).
ibase_fetch_object returns uppercase property names.
So actually this isn't a bug in PHP, but merely the design of
Interbase/Firebird.
Previous Comments:
[2003-05-13 23:15:13] vhcampos at terra dot com dot br
I changed my code to use ibase_fetch_assoc() instead of
ibase_fetch_row() to get an associative array. Surprisingly all field
names are case-sensitive, like ibase_fetch_object()'s properties,
mentioned in a prior message. I believe this behavior is incorrect,
those values should be case-insensitive.
I tried this using Apache 1.3.27 for Windows, Firebird 1.0.2.908 and
PHP versions 4.3.1 and 4.3.2-RC3-dev.
[2003-05-13 21:31:13] vhcampos at terra dot com dot br
You're right about ibase_fetch_row(): I should have read the manual.
As for ibase_fetch_object(), I noticed (after using var_dump()) that
all returned fields are in uppercase, so the example in the manual is
wrong (the email field in the example should be EMAIL). Couldn't it
be case insensitive since all fields in Interbase/Firebird are converted
to uppercase?
[2003-05-13 16:05:30] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
Also, shorten your example script, we don't need HTML in it. And read
the manual, ibase_fetch_row() returns numerical indices. Try doing
var_dump() on the $row with both ibase_fetch_row() and
ibase_fetch_object().
FYI: There's ibase_fetch_assoc() (undocumented for some reason) which
returns the stuff how you expect.
[2003-05-13 12:51:11] vhcampos at terra dot com dot br
I forgot to mention earlier, but if I use $row[1] instead of
$row[name] the field is correctly retrieved.
[2003-05-13 12:49:13] vhcampos at terra dot com dot br
When I use the following code for the following table, PHP returns the
message:
Notice: Undefined index: name in d:\sites\index.php on line 29
when I try to echo($row[name]) (or whatever field I try).
If I try using $row-name after a $row = ibase_fetch_object($rst), I
get the message:
Notice: Undefined property: name in d:\sites\index.php on line 39
The problem doesn't happen if the table is empty.
Interbase table:
CREATE TABLE NAME
(
COD INTEGER NOT NULL,
NAMEVARCHAR(50) CHARACTER SET WIN1252 NOT NULL,
DATE1 TIMESTAMP,
PRIMARY KEY (COD)
);
PHP Example:
?
$local_bd = intranet:D:\Database\Projetos.gdb;
$usuario = SYSDBA;
$senha = masterkey;
$characterSet = WIN1252;
$cn = ibase_connect($local_bd, $usuario, $senha, $characterSet, 0,
3)
or die(Cannot connect to database.);
?
!DOCTYPE HTML PUBLIC -//W3C//DTD HTML 4.0 Transitional//EN
html
head
titleUntitled/title
/head
body
This is just a test.
p
?
$sql = select cod, name, date1 from Name order by name;
$rst = ibase_query($cn, $sql);
while ($row = ibase_fetch_row($rst))
{
echo(ID: . $row[cod] . br\n);
echo(Name: . $row[name] . br\n);
}
ibase_free_result($rst);
$rst = ibase_query($cn, $sql);
while ($row = ibase_fetch_object($rst))
{
echo(ID: . $row-cod . br\n);
echo(Name: . $row-name . br\n);
}
ibase_free_result($rst);
?
/body
/html
?
ibase_close($cn);
?
PS: I'm using Apache 1.3.27 for Windows, PHP 4.3.1 and Firebird
1.0.2.908 (the latest version of Firebird's 1.0 tree).
--
Edit this bug report at http://bugs.php.net/?id=23613edit=1
#32053 [NoF-Csd]: ibase_query(): message length error
ID: 32053
Updated by: [EMAIL PROTECTED]
Reported By: steven dot harrison3 at ntlworld dot com
-Status: No Feedback
+Status: Closed
Bug Type: InterBase related
Operating System: windows 2000 pro
PHP Version: 4.3.9
Previous Comments:
[2006-04-12 13:17:02] garga at FreeBSD dot org
I had the same problem with 4.4.2 version, after update to
php4-STABLE-latest.tar.gz everything worked fine. I think the bug can be
closed.
Thanks
[2005-03-20 18:00:48] [EMAIL PROTECTED]
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to Open. Thank you.
[2005-02-21 19:34:02] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php4-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
[2005-02-21 15:47:50] steven dot harrison3 at ntlworld dot com
Description:
I use a number of if statements to select an SQL string (in this case
to execute a stored procedure in a firebird database)to go in a $query
variable.
When the string is created and ran as a query the following is kicked
out onto the screen:
ibase_query(): message length error(encountered 0, expected 7346) in
a typical sql string generated may be:
EXECUTE PROCEDURE SEARCH_ALL_PARAM('Teesside','business
planning','Middlesbrough','the');
The parameters are taken from 4 fields on a search web page.
Reproduce code:
---
//Stored procedures used:
//SEARCH_NO_PARAM - where all the search boxes have 'any' and keyword
''
if ($provider == any $level == any $location == any
$keyword == )
{
$query = EXECUTE PROCEDURE SEARCH_NO_PARAM;;
}
//SEARCH_ALL_PARAM - where all the search boxes have information.
if ($provider != any $level != any $location != any
$keyword != )
{
$query = EXECUTE PROCEDURE
SEARCH_ALL_PARAM('.$provider.','.$level.','.$location.','.$keyword.');;
}
// ### some $query removed to keep things brief. ###
?
div align=centerfont size=+1strongQueries and Reports
about the
courses :/strong /font /div
p align=center
input name=submit type=submit value=back and change
search
input name=button2 type=button
onClick=window.location.replace('Query.php') value=new search
input name=button2 type=button
onClick=window.location.replace('information_syllabus.php')
value=main menu
/p
/form
div align=center
table width=100% border=1
tr bgcolor=#e0ffe0
tdCourse Title/td
td bgcolor=#e0ffe0Location/td
tdEntry requirements/td
/tr
?
$result = ibase_query($db, $query);
while ($row =
ibase_fetch_object($result)) {?
tr bgcolor=#f0fffe
tda href=coursedetail.php?courseid=? echo
$row-ENTRYID;?? echo $row-COURSETITLE;?/a/td
td bgcolor=#f0fffe
?
if ($location==any){
$query2 = SELECT *
FROM TBL_MODULE_DELIVERY Where
ENTRYID='.$row-ENTRYID.';
} else {
$query2 = SELECT *
FROM TBL_MODULE_DELIVERY Where
ENTRYID='.$row-ENTRYID.' AND DELIVERYTOWN='.$location.';
}
echo University provider : ;
if (isset
($row-PROVIDERINSTITUTION)
$row-PROVIDERINSTITUTION!=) {echo $row-PROVIDERINSTITUTION;}else{
echo - ;}
echo BR Delivery Town of
Location(s): ;
$result2 = ibase_query($db,
$query2);
while ($row2 =
ibase_fetch_object($result2)) {
if (isset
($row2-DELIVERYTOWN) $row2-DELIVERYTOWN!=){
echo
$row2-DELIVERYTOWN. - ;
} else {
echo - ;
}
} ?
Expected result:
return a result set from a search of courses in a firebird
#36128 [Sus-Csd]: Interbase PDO
ID: 36128
Updated by: [EMAIL PROTECTED]
Reported By: michael at bluemoon dot com
-Status: Suspended
+Status: Closed
Bug Type: PDO related
Operating System: Linux/Windows
PHP Version: 5.1.2
New Comment:
Fixed in PHP_5_3 branch
Previous Comments:
[2006-04-09 07:48:28] [EMAIL PROTECTED]
Looking for a firebird maintainer.
[2006-01-25 17:08:02] michael at bluemoon dot com
To amend my earlier problem description, it appears that I CAN issue
the SELECT query shown in my previous example successfully. However, it
appears that I cannot retrieve values from TIMESTAMP-type columns.
If I substitute SELECT MY_TIMESTAMP_FIELD FROM MY_TABLE for the query
in my original code, it will execute without throwing an exception, but
the value returned is empty (null). The result I am expecting is an
integer (Unix timestamp) value.
I don't know if this constitutes a 'bug' or if I am simply not going
about this the right way. I have tried many of the various permutations
for fetching results as shown in the PDO documentation, but nothing
seems to work.
Is there a way to fetch TIMESTAMP values using the Firebird/Interbase
PDO driver?
[2006-01-23 10:51:33] [EMAIL PROTECTED]
Assigned to the maintainer.
[2006-01-23 02:21:25] michael at bluemoon dot com
Description:
Exception thrown when issuing SELECT query using PDO driver
for Firebird/Interbase. Database Server runs Interbase 7.5.x
(Linux).
Problem occurs with PHP 5.1.2 running in both Linux/Apache 2
and Windows 2000/IIS environments.
Tried running PHP alternately with Interbase 6 and 7.5 Run-
time Client Libraries on each platform; same problem.
Native PHP Firebird/Interbase functions (e.g., ibase_connect
(), etc.) functions work fine in same environments used to
test PDO functions.
Confirmed DSN string used in my PDO connection function is
correct by testing PDO::ATTR_CONNECTION_STATUS attribute;
value returned is 1.
Reproduce code:
---
try {
$dbh = new PDO($dsn, $user, $password, array(
PDO::ATTR_PERSISTENT = true
));
$dbh-setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
$stmt = $dbh-prepare(SELECT Count(*) FROM MY_TABLE);
$stmt-execute();
$row = $stmt-fetch(PDO::FETCH_NUM);
$stmt = null;
echo $row[0];
}
catch (PDOException $e) {
die $e-getMessage();
}
Expected result:
Should output integer value result from SELECT query to screen
Actual result:
--
Outputs the following error:
SQLSTATE[HY000]: General error: -804 Dynamic SQL Error SQL
error code = -804 Incorrect values within SQLDA structure
--
Edit this bug report at http://bugs.php.net/?id=36128edit=1
#39822 [Sus-Csd]: new PDO() doesn't work with firebird
ID: 39822
Updated by: [EMAIL PROTECTED]
Reported By: bx at clansphere dot de
-Status: Suspended
+Status: Closed
Bug Type: PDO related
Operating System: Windows XP SP2
PHP Version: 5CVS-2006-12-13 (snap)
Assigned To: wez
New Comment:
Fixed in CVS (PHP_5_3 branch)
Previous Comments:
[2007-10-12 20:21:45] Lars dot Westermann at privat dot dk
The above mentioned block didn't print the correct error-code; use this
instead:
if (!dbh-methods) {
char errmsg[512];
long *pvector = H-isc_status;
isc_interprete(errmsg, pvector);
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
SQLSTATE[%s] [%d] %s,
HY000, (short) H-isc_status[1], errmsg);
}
(Use the (short) typecast to get the correct error-code)
Greetings,
Lars
[2007-10-12 20:14:26] Lars dot Westermann at privat dot dk
Maybe not the correct way of doing this, but it works:
In ext/pdo_firebird/firebird_driver.c:
/* the driver-specific PDO handle constructor */
static int pdo_firebird_handle_factory(pdo_dbh_t *dbh, zval
*driver_options TSRMLS_DC) /* {{{ */
{
struct pdo_data_src_parser vars[] = {
{ dbname, NULL, 0 },
{ charset, NULL, 0 },
{ role, NULL, 0 }
};
int i, ret = 0;
short buf_len = 256, dpb_len;
pdo_firebird_db_handle *H = dbh-driver_data =
pecalloc(1,sizeof(*H),dbh-is_persistent);
php_pdo_parse_data_source(dbh-data_source, dbh-data_source_len,
vars, 3);
do {
static char const dpb_flags[] = {
isc_dpb_user_name, isc_dpb_password, isc_dpb_lc_ctype,
isc_dpb_sql_role_name };
char const *dpb_values[] = { dbh-username, dbh-password,
vars[1].optval, vars[2].optval };
char dpb_buffer[256] = { isc_dpb_version1 }, *dpb;
dpb = dpb_buffer + 1;
/* loop through all the provided arguments and set dpb fields
accordingly */
for (i = 0; i sizeof(dpb_flags); ++i) {
if (dpb_values[i] buf_len 0) {
dpb_len = slprintf(dpb, buf_len, %c%c%s,
dpb_flags[i], (unsigned char)strlen(dpb_values[i]),
dpb_values[i]);
dpb += dpb_len;
buf_len -= dpb_len;
}
}
/* fire it up baby! */
if (isc_attach_database(H-isc_status, 0, vars[0].optval,
H-db,(short)(dpb-dpb_buffer), dpb_buffer)) {
break;
}
dbh-methods = firebird_methods;
dbh-native_case = PDO_CASE_UPPER;
dbh-alloc_own_columns = 1;
ret = 1;
} while (0);
for (i = 0; i sizeof(vars)/sizeof(vars[0]); ++i) {
if (vars[i].freeme) {
efree(vars[i].optval);
}
}
if (!dbh-methods) {
char errmsg[512];
long *pvector = H-isc_status;
isc_interprete(errmsg, pvector);
zend_throw_exception_ex(php_pdo_get_exception(), 0 TSRMLS_CC,
SQLSTATE[%s] [%d] %s,
HY000, (long) H-isc_status[1], errmsg);
}
if (!ret) {
firebird_handle_closer(dbh TSRMLS_CC);
}
return ret;
}
/* }}} */
IMHO the _firebird_error() function should be written like the
functions in pdo_pgsql and pdo_mysql, which - to mee - look like they
are built on the same template - and the firebird version is not.
But the above codeblock containing the zend_throw_exception_ex() does
it's job and prints the firebird errormessage.
Hope it at least can serve as a quick fix, until the a more correct
approach (better error-handler) has been made.
Greetings,
Lars
[2006-12-18 15:26:50] [EMAIL PROTECTED]
Looking for a maintainer
[2006-12-13 22:08:25] bx at clansphere dot de
Description:
using try/catch doesn't work for firebird like it works with other
rdbms extensions. i think the problem is that firebird returns something
(NULL) so that try expects all went well, but it is not checking for the
PDO object itself.
i am using is_object() currently to look for errors, but that way i
can't get errorcodes like 'database does not exist' for example and even
when track_errors is enabled $php_errormsg is empty.
Reproduce code:
---
try {
$connection = new PDO('firebird:dbname=test.fdb', $user,
$password);
}
catch(PDOException $error) {
echo $error-getMessage();
}
Expected result:
catch can be called to get the exact error
Actual result:
--
try statement thinks everything is ok
--
Edit this bug report at http://bugs.php.net/?id=39822edit=1
#41522 [Asn-Csd]: PDO firebird driver returns null if it fails to connect
ID: 41522 Updated by: [EMAIL PROTECTED] Reported By: mark-phpbugs at vectrex dot org dot uk -Status: Assigned +Status: Closed Bug Type: PDO related Operating System: Linux PHP Version: 5.2.2 Assigned To: abies New Comment: Fixed in CVS (PHP_5_3 branch) Previous Comments: [2007-10-12 20:26:01] Lars dot Westermann at privat dot dk See comment for bug #39822, where a fix is suggested. Greetings, Lars [2007-05-28 17:08:09] mark-phpbugs at vectrex dot org dot uk Description: The firebird PDO driver returns nothing, or null if it fails to connect - this is contradictory to what the PDO documentation says (should throw PDOException) and the behaviour of the other drivers. Reproduce code: --- $conn = new PDO(firebird:dbname=localhost:test.fdb, 'SYSDBA','wrong password'); Expected result: It should throw a PDOException, ideally with an explanation or error code. Actual result: -- Returns NULL with no errors or warnings even with error_reporting(E_ALL) -- Edit this bug report at http://bugs.php.net/?id=41522edit=1
#35386 [Sus-Csd]: firebird: first row is null
ID: 35386
Updated by: [EMAIL PROTECTED]
Reported By: slapaf at hotmail dot com
-Status: Suspended
+Status: Closed
Bug Type: PDO related
Operating System: winxp sp2
PHP Version: 5CVS-2006-12-02 (snap)
Assigned To: jacques
New Comment:
Fixed in CVS (PHP_5_3 branch)
Previous Comments:
[2007-10-12 17:31:08] Lars dot Westermann at privat dot dk
Well, tried to dig into this ...
After some trial and error, I found this little quick and dirty trick,
which solves (or rather works around) another quick and dirty trick ...
Try this in etc/pdo_firebird/firebird_statement.c:
/* called by PDO to retrieve information about the fields being
returned */
static int firebird_stmt_describe(pdo_stmt_t *stmt, int colno
TSRMLS_DC) /* {{{ */
{
pdo_firebird_stmt *S = (pdo_firebird_stmt*)stmt-driver_data;
struct pdo_column_data *col = stmt-columns[colno];
XSQLVAR *var = S-out_sqlda.sqlvar[colno];
/* allocate storage for the column */
var-sqlind = (void*)emalloc(var-sqllen + 2*sizeof(short));
var-sqldata = ((char*)var-sqlind)[sizeof(short)];
col-precision = -var-sqlscale;
col-maxlen = var-sqllen;
col-namelen = var-aliasname_length;
col-name = estrndup(var-aliasname,var-aliasname_length);
/*
* Compensates for hack in another function:
* Force data-type in column to string
*/
col-param_type = PDO_PARAM_STR;
/* = */
return 1;
}
/* }}} */
The same hack is found in same module, in another function, but AFTER
the columntype is set for the first row - hence it works for the
subsequent rows ...
static int firebird_stmt_get_col(pdo_stmt_t *stmt, int colno, char
**ptr, /* {{{ */
unsigned long *len, int *caller_frees TSRMLS_DC)
{
pdo_firebird_stmt *S = (pdo_firebird_stmt*)stmt-driver_data;
XSQLVAR const *var = S-out_sqlda.sqlvar[colno];
if (*var-sqlind == -1) {
/* A NULL value */
*ptr = NULL;
*len = 0;
} else {
/* override the column param type */
/* set_param_type(stmt-columns[colno].param_type,var); */
=stmt-columns[colno].param_type = PDO_PARAM_STR;
if (var-sqlscale 0) {
static ISC_INT64 const scales[] = { 1, 10, 100, 1000,
1, 10, 100,
1, 10, 10,
LL_LIT(100),LL_LIT(1000),
The row pointed to above (=) could/should be removed, as
columntype definition _should_ be handled in firebird_stmt_describe()
function (where my hack resides).
I have tested this with PHP 5.2.4 on Fedora Core 7 - and this hack
works. I miss the total overview of PDO, so I can't reactivate the
code-parts originally handling conversion from native Firebird/Interbase
sql-type to PDO datatype constants. But this work should be done. If I
have/get the time, and come to understand the code better, I would be
happy to contribute.
For now I hope the above can help anyone, who compile the source, and
that this quick and dirty hack can make it into the next release
(5.2.5?) of PHP. It works, but is not the long term solution, I think.
Greetings,
Lars
[2007-10-09 00:07:26] acerb at softhome dot net
System :
Windows NT 5.1 build 2600 (MS Windows XP SP2)
Apache 2.0
PHP 5.1.2 5.2.3
I tried several methods :
PDOStatement-fetchAll(), PDOStatement-fetch(), PDO-query()
with arguments :
PDO::FETCH_NUM, PDO::FETCH_ASSOC, PDO::FETCH_LAZY,
PDO::FETCH_COLUMN, PDO::FETCH_GROUP
same result : First row is missing
Array (
[LAN_ID] =
[LAN_NAME_EN] =
[LAN_CODE] = )
Array (
[LAN_ID] = 2
[LAN_NAME_EN] = FRENCH
[LAN_CODE] = FR )
Array (
[LAN_ID] = 3
[LAN_NAME_EN] = ENGLISH
[LAN_CODE] = EN )
I tried with different tables and select statements and I always got
the same result. As it seems to be a pretty obvious bug/error, could it
be corrected in the next release (of PHP), please ?
[2007-10-04 09:11:55] tetikr at spytech dot cz
This is quite an old bug (2 years!) and yet not fixed in 5.2.4.
Ridiculous! I'm using Doctrine with Firebird and it makes me crazy. Do
something about it, please.
[2007-08-20 15:47:04] dong_peng at 163 dot com
I have met the same problem.
OS : Windows XP SP2
PHP: 5.2.3
Firebird : WI-V6.3.1.12855 Firebird 2.0
I have a simple table named school in my database, the CREATE TABLE
statement is as below :
CREATE TABLE school
( school_code SMALLINT PRIMARY KEY,
school_name VARCHAR(40) NOT NULL,
short_name VARCHAR(20)
);
And there were total 14 rows in the table,
