#38161 [Com]: oci_bind_by_name return memory dump
ID: 38161 Comment by: cjbj at hotmail dot com Reported By: a dot bodemer at brillux dot de Status: Feedback Bug Type: OCI8 related Operating System: Linux x86 PHP Version: 5.1.4 New Comment: Tony you shouldn't need a stack dump for this. Just try a var_dump($returnValue) at the end of the script. Because no value has been returned in the variable it is being treated as a 64K string and printing garbage. The workaround for users is to make sure that the PL/SQL block always sets variable values in all possible code paths. Something like: $query= "declare n_status NUMBER(2); begin :retValue := 0; -- set default value n_status := 1 ; IF :n_status = 0 THEN :retValue := :n_status; END IF; end;"; Previous Comments: [2006-07-20 15:48:02] [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-20 15:05:00] a dot bodemer at brillux dot de The SampleCode produce in php5.2-200607190630 the same result, a memory dump. In all Testcases the script run without a PHP Error message or a 'Segmentation Failure'. [2006-07-20 14:18:03] [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-07-20 14:16:20] a dot bodemer at brillux dot de Description: Hallo, we use a Linux/Apache/Oracle/PHP on a X86 system. We tested the Codesample on PHP 5.1.4 with Oracle 8.1/10.1 and Apache 2.0.46/2.0.58. Every times the same result, a memory dump from the current apache. Reproduce code: --- OCIExecute() ret=$ret"; print "\n Return Value=".$returnValue; ?> Expected result: The return value must be NULL. Actual result: -- The result is a memory dump from the current apache. -- Edit this bug report at http://bugs.php.net/?id=38161&edit=1
#37487 [NEW]: oci_fetch_array() array-type should always default to OCI_BOTH
From: cjbj at hotmail dot com
Operating system: n/a
PHP version: 5.1.4
PHP Bug Type: OCI8 related
Bug description: oci_fetch_array() array-type should always default to OCI_BOTH
Description:
The array type for oci_fetch_array() should always default to OCI_BOTH
unless explicitly changed. For example, currently
oci_fetch_array($s)
is equivalent to
oci_fetch_array($s, OCI_BOTH)
I'm saying that
oci_fetch_array($s, OCI_RETURN_NULLS)
should be equivalent to
oci_fetch_array($s, OCI_RETURN_NULLS+OCI_BOTH)
At the moment it is equivalent to
oci_fetch_array($s, OCI_RETURN_NULLS+OCI_NUM)
which is (i) not documented (ii) harder to understand and document.
Reproduce code:
---
"; var_dump($res); echo "";
}
oci_execute($s);
while ($res = oci_fetch_array($s)) {
echo ""; var_dump($res); echo "";
}
oci_close($c);
?>
Expected result:
array(2) {
[0]=>
string(1) "X"
["DUMMY"]=>
string(1) "X"
}
array(2) {
[0]=>
string(1) "X"
["DUMMY"]=>
string(1) "X"
}
Actual result:
--
array(1) {
[0]=>
string(1) "X"
}
array(2) {
[0]=>
string(1) "X"
["DUMMY"]=>
string(1) "X"
}
--
Edit bug report at http://bugs.php.net/?id=37487&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37487&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37487&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37487&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37487&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37487&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37487&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37487&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37487&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37487&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37487&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37487&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37487&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37487&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37487&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37487&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37487&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37487&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37487&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37487&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37487&r=mysqlcfg
#37392 [NEW]: Unnecessary call to OCITransRollback() at the end of request
From: cjbj at hotmail dot com
Operating system: n/a
PHP version: 5.1.4
PHP Bug Type: OCI8 related
Bug description: Unnecessary call to OCITransRollback() at the end of request
Description:
Php_oci_persistent_helper() calls php_oci_connection_rollback() without
checking connection->needs_commit. This results in an unnecessary call to
OCITransRollback() at the end of request for persistent connections.
Reproduce code:
---
";
oci_internal_debug(1);
$conn = oci_pconnect("hr", "hr", "//localhost/XE");
$query = 'select * from dual';
$stid = oci_parse($conn, $query);
oci_execute($stid, OCI_DEFAULT);
oci_rollback($conn);
echo "";
?>
Expected result:
...
OCI8 DEBUG: OCITransRollback at (/tmp/php-5.1.3/ext/oci8/oci8.c:1400)
OCI8 DEBUG: OCIStmtRelease at
(/tmp/php-5.1.3/ext/oci8/oci8_statement.c:589)
...
Actual result:
--
...
OCI8 DEBUG: OCITransRollback at (/tmp/php-5.1.3/ext/oci8/oci8.c:1400)
OCI8 DEBUG: OCITransRollback at (/tmp/php-5.1.3/ext/oci8/oci8.c:1400)
OCI8 DEBUG: OCIStmtRelease at
(/tmp/php-5.1.3/ext/oci8/oci8_statement.c:589)
...
--
Edit bug report at http://bugs.php.net/?id=37392&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=37392&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=37392&r=trysnapshot52
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=37392&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=37392&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=37392&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=37392&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=37392&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=37392&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=37392&r=support
Expected behavior:http://bugs.php.net/fix.php?id=37392&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=37392&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=37392&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=37392&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=37392&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=37392&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=37392&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=37392&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=37392&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=37392&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=37392&r=mysqlcfg
#37218 [Com]: oci_new_collection crash Apache
ID: 37218
Comment by: cjbj at hotmail dot com
Reported By: xfree at inbox dot lv
Status: Open
Bug Type: OCI8 related
Operating System: Windows
PHP Version: 5.1.2
Assigned To: tony2001
New Comment:
I don't get a crash with PHP 5.1.3, but do get an error 'OCI-22303:
type ""."myCollection" not found'.
To work, the name must be in uppercase in the oci_new_collection()
call:
$lora_coll = oci_new_collection($lora_conn, 'MYCOLLECTION');
Previous Comments:
[2006-05-02 06:27:40] xfree at inbox dot lv
the same error with the latest snapshot..
[2006-05-01 07:12: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-04-27 07:03:38] xfree at inbox dot lv
Description:
Oci_new_collection crash Apache Web Server running on Windows XP. Then
I calling this function - Apache just stops, with windows like error
message “Apache service raise an error and will be
closed.”
Configuration is following:
PHP 5.1.2. Apache 2.0.55. Oracle Database 10.1.3.
phpinfo() shows:
Temporary Lob support enabled
Collections support enabled.
Collection type is very simple:
create or replace type myCollection as table of varchar2(4000);
/
Reproduce code:
---
// connect to ora
$lora_conn = oci_connect(_LOGIN, _PASSWD, _TNSNAME);
if ($lora_conn)
{
$lora_coll = oci_new_collection($lora_conn, 'myCollection');
//...
}
Actual result:
--
Apache service crash.
--
Edit this bug report at http://bugs.php.net/?id=37218&edit=1
#36851 [NEW]: Documentation and code discrepancies for NULL data
From: cjbj at hotmail dot com
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: OCI8 related
Bug description: Documentation and code discrepancies for NULL data
Description:
Doc bug 1: oci_fetch_array(). The manual
http://www.php.net/manual/en/function.oci-fetch-array.php says
oci_fetch_array() returns an array with both associative and
numeric indices.
Note: This function sets NULL fields to PHP NULL value.
My testing shows the default does not return NULLs. The above Note
should be removed from the documentation.
The manual later says that OCI_RETURN_NULLS is an option. Using this
does return NULLs as expected.
Code bug 1: oci_fetch_assoc documentation says "Note: This function
sets NULL fields to PHP NULL value." This is not true. I'd treat
this as a code bug, since it makes it hard to code in some styles -
you have to code special case checks for each column since no entry
may exist. Also there are no optional parameters to alter the
behavior.
Code bug 2: oci_fetch_object: same problem as oci_fetch_assoc.
Code bug 3: oci_fetch_row: same problem as oci_fetch_assoc.
Only oci_fetch_all() honors the documentation and returns NULLs.
Reproduce code:
---
";
$c = oci_connect("hr", "hr", "//localhost/XE");
$stid = oci_parse($c, "select 'abc', null, 'ghi' from dual");
echo "Fetch All\n";
oci_execute($stid, OCI_DEFAULT);
oci_fetch_all($stid, $res);
var_dump($res);
echo "Fetch as Array\n";
oci_execute($stid, OCI_DEFAULT);
$res = oci_fetch_array($stid);
var_dump($res);
echo "Associative Array\n";
oci_execute($stid, OCI_DEFAULT);
$res = oci_fetch_assoc($stid);
var_dump($res);
echo "Object\n";
oci_execute($stid, OCI_DEFAULT);
$res = oci_fetch_object($stid);
var_dump($res);
echo "Numeric Array\n";
oci_execute($stid, OCI_DEFAULT);
$res = oci_fetch_row($stid);
var_dump($res);
oci_close($c);
echo "";
?>
Actual result:
--
Fetch All
array(3) {
["'ABC'"]=>
array(1) {
[0]=>
string(3) "abc"
}
["NULL"]=>
array(1) {
[0]=>
NULL
}
["'GHI'"]=>
array(1) {
[0]=>
string(3) "ghi"
}
}
Fetch as Array
array(4) {
[0]=>
string(3) "abc"
["'ABC'"]=>
string(3) "abc"
[2]=>
string(3) "ghi"
["'GHI'"]=>
string(3) "ghi"
}
Associative Array
array(2) {
["'ABC'"]=>
string(3) "abc"
["'GHI'"]=>
string(3) "ghi"
}
Object
object(stdClass)#1 (2) {
["'ABC'"]=>
string(3) "abc"
["'GHI'"]=>
string(3) "ghi"
}
Numeric Array
array(2) {
[0]=>
string(3) "abc"
[2]=>
string(3) "ghi"
}
--
Edit bug report at http://bugs.php.net/?id=36851&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36851&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36851&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36851&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36851&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36851&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36851&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36851&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36851&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36851&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36851&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36851&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36851&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36851&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36851&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36851&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36851&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36851&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36851&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36851&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36851&r=mysqlcfg
#36820 [NEW]: Privileged connection with an Oracle password file fails
From: cjbj at hotmail dot com
Operating system: Linux
PHP version: 5.1.2
PHP Bug Type: OCI8 related
Bug description: Privileged connection with an Oracle password file fails
Description:
When oci_connect() uses OCI_SYSDBA or OCI_SYSOPER, oci8.c always calls
OCISessionBegin() with OCI_CRED_EXT. This needs to be changed to
OCI_CRED_RDBMS in some cases so privileged connections can be
authenticated by an Oracle password file.
When OCI_SYSDBA or OCI_SYSOPER are specified:
if the username is "/" and there is no password then
the credential should be OCI_CRED_EXT
else
the credential should be OCI_CRED_RDBMS
There are two success cases of interest:
Case 1: oci8.c should use OCI_CRED_EXT.
Connect succeds if the process running PHP is in Oracle's OS dba
group and the DB is "local" i.e on the same host and specified by
ORACLE_SID environment variable. Otherwise connection will fail.
oci_connect("/", "", NULL, OCI_SYSDBA);
Case 2: oci8.c should use OCI_CRED_RDBMS.
Connect succeeds if the user is in Oracle's password file. The DB
can be on a remote host.
// Note DB name could be NULL.
oci_connect("un", "pw", "MYSID", OCI_SYSDBA);
Note: the php.ini parameter oci8.privileged_connect must be true for
PHP to allow OCI_SYSDBA or OCI_SYSOPER connections.
Actual result:
--
Currently case 2 gives ORA-01031: insufficient privileges in test.php on
line 3.
--
Edit bug report at http://bugs.php.net/?id=36820&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=36820&r=trysnapshot44
Try a CVS snapshot (PHP 5.1):
http://bugs.php.net/fix.php?id=36820&r=trysnapshot51
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=36820&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=36820&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=36820&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=36820&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=36820&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=36820&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=36820&r=support
Expected behavior:http://bugs.php.net/fix.php?id=36820&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=36820&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=36820&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=36820&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=36820&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=36820&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=36820&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=36820&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=36820&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=36820&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=36820&r=mysqlcfg
#36800 [Com]: nit-pick - oci8_interface.c returns VARCHAR not VARCHAR2
ID: 36800 Comment by: cjbj at hotmail dot com Reported By: jnavratil at houston dot rr dot com Status: Open Bug Type: Feature/Change Request Operating System: Fedora Core 4.2 PHP Version: 5.1.2 New Comment: The Oracle 10.2 manuals state: "Although the VARCHAR datatype is currently synonymous with VARCHAR2, the VARCHAR datatype is scheduled to be redefined as a separate datatype used for variable-length character strings compared with different comparison semantics." Previous Comments: [2006-03-20 18:16:57] jnavratil at houston dot rr dot com Description: (extreme nit-pick) oci_field_type returns 'VARCHAR' for a SQLT_CHR. It should more accurately return 'VARCHAR2' as 'VARCHAR' is deprecated. -- Edit this bug report at http://bugs.php.net/?id=36800&edit=1
#36607 [Com]: default_prefetch problem w/ dbLinks
ID: 36607 Comment by: cjbj at hotmail dot com Reported By: jreed at myers dot com Status: Open Bug Type: OCI8 related Operating System: Linux - 386 PHP Version: 5.1.2 New Comment: I'd contact Oracle Support about this. Give them the stack trace. There seems to be a couple of recent 10.2 reports to Oracle with a similar trace. Previous Comments: [2006-03-08 19:05:25] jreed at myers dot com As stated previously, Oracle Instant Client v10.2. Server version is 10.2 with dbLink v10.2 which links to a database v8i. To create the dblink: create database link linkname connect to username identified by password using databasename; [2006-03-08 07:37:43] cjbj at hotmail dot com That stack trace is pretty deep in Oracle. In case this problem needs to be reported to them, what is the version of the Oracle client libraries that PHP is linked with? What is the Oracle server version? How are you creating the DB link? [2006-03-07 20:42:19] jreed at myers dot com Here's the backtrace with all Zend extensions removed/turned off: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -150626176 (LWP 20044)] 0x020683da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1 (gdb) bt #0 0x020683da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1 #1 0x0205f698 in ttcdrv () from /usr/local/instantclient/lib/libclntsh.so.10.1 #2 0x01f45ec5 in nioqwa () from /usr/local/instantclient/lib/libclntsh.so.10.1 #3 0x01db3d97 in upirtrc () from /usr/local/instantclient/lib/libclntsh.so.10.1 #4 0x01d29a36 in kpurcsc () from /usr/local/instantclient/lib/libclntsh.so.10.1 #5 0x01cdf07b in kpuexecv8 () from /usr/local/instantclient/lib/libclntsh.so.10.1 #6 0x01ce140a in kpuexec () from /usr/local/instantclient/lib/libclntsh.so.10.1 #7 0x01db8902 in OCIStmtExecute () from /usr/local/instantclient/lib/libclntsh.so.10.1 #8 0x00476205 in php_oci_statement_execute (statement=0x862fa5c, mode=140695500) at /root/php5.1-200603062130/ext/oci8/oci8_statement.c:321 #9 0x0047b712 in zif_oci_execute (ht=2, return_value=0x871c724, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /root/php5.1-200603062130/ext/oci8/oci8_interface.c:1276 #10 0x011f472d in zend_do_fcall_common_helper_SPEC (execute_data=0xfef46920) at zend_vm_execute.h:192 #11 0x011f40a1 in execute (op_array=0x8606cd8) at zend_vm_execute.h:92 #12 0x011f452f in zend_do_fcall_common_helper_SPEC (execute_data=0xfef4df30) at zend_vm_execute.h:226 #13 0x011f40a1 in execute (op_array=0x85be084) at zend_vm_execute.h:92 #14 0x011df7be in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-5.1.2/Zend/zend.c:1101 #15 0x011aef24 in php_execute_script (primary_file=0xfef50270) at /root/php-5.1.2/main/main.c:1720 #16 0x01236f08 in php_handler (r=0x85ab410) at /root/php-5.1.2/sapi/apache2handler/sapi_apache2.c:584 #17 0x080765b2 in ap_run_handler (r=0x85ab410) at config.c:157 #18 0x08076ac6 in ap_invoke_handler (r=0x85ab410) at config.c:371 #19 0x08092eff in ap_process_request (r=0x85ab410) at http_request.c:258 #20 0x08090fd1 in ap_process_http_connection (c=0x85a5238) at http_core.c:171 #21 0x0807bb02 in ap_run_process_connection (c=0x85a5238) at connection.c:43 #22 0x080a09f7 in child_main (child_num_arg=0) at prefork.c:640 #23 0x080a0af0 in make_child (s=0x83d1fd0, slot=0) at prefork.c:680 #24 0x080a1531 in ap_mpm_run (_pconf=0x83cd0a8, plog=0x8409198, s=0x83d1fd0) at prefork.c:956 #25 0x08066f5c in main (argc=2, argv=0xfef50634) at main.c:712 [2006-03-07 18:52:41] jreed at myers dot com Same result with no Zend extensions. I am the only one with Zend extensions installed. Others who never installed Zend have the same problem. [2006-03-07 08:38:52] [EMAIL PROTECTED] Disable all zend_extensions and try again. 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/36607 -- Edit this bug report at http://bugs.php.net/?id=36607&edit=1
#36607 [Com]: default_prefetch problem w/ dbLinks
ID: 36607 Comment by: cjbj at hotmail dot com Reported By: jreed at myers dot com Status: Open Bug Type: OCI8 related Operating System: Linux - 386 PHP Version: 5.1.2 New Comment: That stack trace is pretty deep in Oracle. In case this problem needs to be reported to them, what is the version of the Oracle client libraries that PHP is linked with? What is the Oracle server version? How are you creating the DB link? Previous Comments: [2006-03-07 20:42:19] jreed at myers dot com Here's the backtrace with all Zend extensions removed/turned off: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -150626176 (LWP 20044)] 0x020683da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1 (gdb) bt #0 0x020683da in ttcfopr () from /usr/local/instantclient/lib/libclntsh.so.10.1 #1 0x0205f698 in ttcdrv () from /usr/local/instantclient/lib/libclntsh.so.10.1 #2 0x01f45ec5 in nioqwa () from /usr/local/instantclient/lib/libclntsh.so.10.1 #3 0x01db3d97 in upirtrc () from /usr/local/instantclient/lib/libclntsh.so.10.1 #4 0x01d29a36 in kpurcsc () from /usr/local/instantclient/lib/libclntsh.so.10.1 #5 0x01cdf07b in kpuexecv8 () from /usr/local/instantclient/lib/libclntsh.so.10.1 #6 0x01ce140a in kpuexec () from /usr/local/instantclient/lib/libclntsh.so.10.1 #7 0x01db8902 in OCIStmtExecute () from /usr/local/instantclient/lib/libclntsh.so.10.1 #8 0x00476205 in php_oci_statement_execute (statement=0x862fa5c, mode=140695500) at /root/php5.1-200603062130/ext/oci8/oci8_statement.c:321 #9 0x0047b712 in zif_oci_execute (ht=2, return_value=0x871c724, return_value_ptr=0x0, this_ptr=0x0, return_value_used=0) at /root/php5.1-200603062130/ext/oci8/oci8_interface.c:1276 #10 0x011f472d in zend_do_fcall_common_helper_SPEC (execute_data=0xfef46920) at zend_vm_execute.h:192 #11 0x011f40a1 in execute (op_array=0x8606cd8) at zend_vm_execute.h:92 #12 0x011f452f in zend_do_fcall_common_helper_SPEC (execute_data=0xfef4df30) at zend_vm_execute.h:226 #13 0x011f40a1 in execute (op_array=0x85be084) at zend_vm_execute.h:92 #14 0x011df7be in zend_execute_scripts (type=8, retval=0x0, file_count=3) at /root/php-5.1.2/Zend/zend.c:1101 #15 0x011aef24 in php_execute_script (primary_file=0xfef50270) at /root/php-5.1.2/main/main.c:1720 #16 0x01236f08 in php_handler (r=0x85ab410) at /root/php-5.1.2/sapi/apache2handler/sapi_apache2.c:584 #17 0x080765b2 in ap_run_handler (r=0x85ab410) at config.c:157 #18 0x08076ac6 in ap_invoke_handler (r=0x85ab410) at config.c:371 #19 0x08092eff in ap_process_request (r=0x85ab410) at http_request.c:258 #20 0x08090fd1 in ap_process_http_connection (c=0x85a5238) at http_core.c:171 #21 0x0807bb02 in ap_run_process_connection (c=0x85a5238) at connection.c:43 #22 0x080a09f7 in child_main (child_num_arg=0) at prefork.c:640 #23 0x080a0af0 in make_child (s=0x83d1fd0, slot=0) at prefork.c:680 #24 0x080a1531 in ap_mpm_run (_pconf=0x83cd0a8, plog=0x8409198, s=0x83d1fd0) at prefork.c:956 #25 0x08066f5c in main (argc=2, argv=0xfef50634) at main.c:712 [2006-03-07 18:52:41] jreed at myers dot com Same result with no Zend extensions. I am the only one with Zend extensions installed. Others who never installed Zend have the same problem. [2006-03-07 08:38:52] [EMAIL PROTECTED] Disable all zend_extensions and try again. [2006-03-07 01:05:24] jreed at myers dot com Backtrace already provided. [2006-03-07 01:02:03] [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. "Always disable any Zend or other 3rd party extensions (Turck MMCache, ionCube loader, Xdebug, APC) before submitting a *PHP* 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/36607 -- Edit this bug report at http://bugs.php.net/?id=36607&edit=1
#36649 [Com]: ORA-12154: using Oracle 9i
ID: 36649
Comment by: cjbj at hotmail dot com
Reported By: madlybad at hotmail dot com
Status: Open
Bug Type: OCI8 related
Operating System: Windows XP Pro SP2
PHP Version: 5.1.2
New Comment:
The bug system is not the best place to ask this question.
Refer to notes like
http://www.oracle.com/technology/tech/php/htdocs/php_troubleshooting_faq.html
and check all your environment variables - e.g. ORACLE_HOME - are set
correctly in the shell environment that starts the web server.
Previous Comments:
[2006-03-07 22:36:04] madlybad at hotmail dot com
Description:
My configuration to connect to Oracle 9i is correct. I am able to
connect to Oracle 9i using SQLPLus and TOAD. But using PHP I am unable
to connect to Oracle this error appears "ORA-12154: TNS:could not
resolve the connect identifier specified".
Reproduce code:
---
';
while ($fila = oci_fetch_array($id_sentencia, OCI_RETURN_NULLS)) {
print '';
foreach ($fila as $item) {
print ''.($item?htmlentities($item):' ').'';
}
print '';
}
print '';
oci_close($conexion);
?>
Expected result:
connected!
Actual result:
--
ORA-12154: TNS:could not resolve the connect identifier specified
--
Edit this bug report at http://bugs.php.net/?id=36649&edit=1
#36250 [Com]: PHP Causes ORA-07445 Core dump in Oracle server 9.2.x
ID: 36250 Comment by: cjbj at hotmail dot com Reported By: fred dot cohen at iridium dot com Status: Open Bug Type: OCI8 related Operating System: Solaris 9 PHP Version: 5.1.2 New Comment: OCIPing requires 10.1 or 10.2 OCI client libraries. It will (or should) return a nice error when the database server is 8.1 or 9.2. This won't help PHP validate the connection as intended when connected to these older databases. The oci8 extension should just use OCIServerVersion. The OCI Developers are against the concept of pinging for each connection because it is an unneccessary round-trip between OCI client and database server. Previous Comments: [2006-03-06 22:19:53] fred dot cohen at iridium dot com That's what Oracle is telling us. This is directly from our ticket with them: I think there are 2 things you can do to fix your problem. 1. Install the 10.2 listener in the box where your 10.1.x or your 9.x database are running and use that listener to listen for your databases. 2. Fix the OCI8 driver for PHP so it does not use OCIPING at all We're awaiting further response from Oracle because their response conflicts with all the documentation I've been able to find on OCI and the OCIPing function. [2006-03-05 08:43:35] [EMAIL PROTECTED] So you're effectively saying that OCIPing() which exists in OIC is not supported by Oracle servers 8 and 9 and causes them to crash? This sounds really.. hmm.. weird, because I was recommended to use OCIPing() namely by Oracle developers. [2006-03-04 07:41:10] fred dot cohen at iridium dot com It might be a good idea get the Server Version with a call to OCIServerVersion rather than relying on the OCI_xx_VERSION defines. Any of the developers care to comment? #if OCI_MAJOR_VERSION >= 10 && OCI_MINOR_VERSION >= 2 /* OCIPing() is usable only in 10.2 */ OCI_G(errcode) = PHP_OCI_CALL(OCIPing, (connection->svc, OCI_G(err), OCI_DEFAULT)); #else char version[256]; /* use good old OCIServerVersion() by default */ OCI_G(errcode) = PHP_OCI_CALL(OCIServerVersion, (connection->server, OCI_G(err), (text*)version, sizeof(version), OCI_HTYPE_SERVER)); #endif [2006-03-04 07:33:51] fred dot cohen at iridium dot com Oracle is claiming OCIPing isn't a supported in anything less than oracle 10.2 [2006-02-01 19:49:51] fred dot cohen at iridium dot com Description: This isn't a bug in PHP, but I'm submitting it since Oracle currently has no patch available and it's cause isn't obvious. Using the Instant Client 10.2 and PHP 5.1.2 connecting to Oracle 9.2.0.7 we began seeing ORA-07445 errors immediately after upgrading to the versions listed. They may appear to occur intermittently, but they can happen as frequently as the oci8.ping_interval value. I've traced it down to the OCIPing call in the oci extension. It turns out any calls to OCIPing cause the error in the server. Workaround: In php.ini [oci8] section, set: oci8.ping_interval=-1 I'll provide updates about possible patches from Oracle as soon as they're able to respond. -- Edit this bug report at http://bugs.php.net/?id=36250&edit=1
#36545 [Com]: OCIEnvNlsCreate() failed
ID: 36545
Comment by: cjbj at hotmail dot com
Reported By: jistanidiot at gmail dot com
Status: Open
Bug Type: OCI8 related
Operating System: RHEL4
PHP Version: 5.1.2
New Comment:
Can you verify that the same version of Oracle was used in yours tests
with PHP 5.0.3 and 5.1.x? Oracle 10.2 defaults to a stricter set of
directory permissions than previous versions of Oracle. The only time
I've seen this problem has been when the version of Oracle changed.
Previous Comments:
[2006-02-27 18:19:59] jistanidiot at gmail dot com
Description:
When any oci_connect is called an error message about OCIEnvNlSCreate()
failing is produced.
Workaround: add the apache user to the oracle group. This only occurs
in 5.2.1. Previous versions of PHP which I've tried (5.0.3 and 5.1.0)
did not have this problem. Obviously this is a security issue as the
apache user now has a lot more things it can use to wreak havoc.
Oracle version 10.2.0.1.0. Apache version 2.0.52.
OS: Red Hat Enterprise Linux ES 4.
Reproduce code:
---
$conn = oci_connect('user', 'pass', 'db');
if (!$conn) {
$e = oci_error();
print htmlentities($e['message']);
exit;
}
Expected result:
Expect to actually connect to the database
Actual result:
--
[error] PHP Warning: oci_connect() [function.oci-connect]:
OCIEnvNlsCreate() failed. There is something wrong with your system -
please check that ORACLE_HOME is set and points to the right directory
in on line
--
Edit this bug report at http://bugs.php.net/?id=36545&edit=1
#35329 [NoF->Opn]: php.ini location changed between 5.0 and 5.1
ID: 35329 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com -Status: No Feedback +Status: Open Bug Type: *General Issues Operating System: win32 PHP Version: 5.1.0 New Comment: Wez, looks like I'm not the only one hitting it. Does the filemon info from stan64 help you? Previous Comments: [2005-12-13 01:38:12] stan64 at gmail dot com Ok, so I used filemon to see where it checked for php.ini. I put it in php root, that is in path and PHPIniDir. And it finds the file reads it and php don't work. I use the recommended ini configured like the last versions that worked. If I try to put it in Windows then... The read pattern is similiar for alot of scrolling but it never looks for php.ini outside of the php directory. PHP works and says it found the ini in the windows directory. Though the settings n phpinfo do NOT represent the ini I put there. [2005-12-13 01:13:50] stan64 at gmail dot com I have got this bug also on 2 systems with alot of installation methods and with both 5.0.4 and 5.1.1. First off PHP won't work if I set PHPIniDir to a wrong path other than the config file lies within. When it's pointed at the wrong location phpinfo says that it have found a ini file in the windows directory. Though it does not contain such a file. I try to put my file there and it don't read it. It still reads it imaginary file that is supposed to be located in the windows directory. I have read through the installation steps carefully, tried all helpful comments. Tried things I found on google. And all with the same result. [2005-12-06 01:00:08] 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-12-01 18:13:35] thejkwhosaysni at gmail dot com I have exactly the same problem with both php5.1.0 and php5.1.1. Putting php.ini into apache2/bin does not work either. Nor the php directory itself. [2005-11-28 17:10:28] [EMAIL PROTECTED] CWD (why it checked the Apache dir) is now only searched when running under CLI. Either this is really a bug or FAQ in the manual should be changed to say to use Apache/bin (path is checked in 5.0 and 5.1 at least since its the binary location). 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/35329 -- Edit this bug report at http://bugs.php.net/?id=35329&edit=1
#35205 [Com]: oci_connect is not closing opened connections after script execution
ID: 35205
Comment by: cjbj at hotmail dot com
Reported By: robertg2 at hope dot ac dot uk
Status: Feedback
Bug Type: OCI8 related
Operating System: Solaris 8
PHP Version: 5.0.5
Assigned To: tony2001
New Comment:
Antony, I've looked at session cleanup.
Problem 1:
Incorrect order of OCISessionEnd and OCIServerDetach calls in
php_oci_connection_close()
The "Terminating the Application" section in chapter 2 of the OCI
manual: http://download-west.oracle.com/docs/cd/B19306_01/
appdev.102/b14250/oci02bas.htm#sthref217 says to call
OCISessionEnd before calling OCIServerDetach.
Problem 2:
In php_oci_connection_close(), connection->session is used after
it has been freed.
Problem 3:
In php_oci_connection_close() why are there some "free" and some
"efree" calls?
Problem 4:
In php_oci_cleanup_global_handles() the error handle should be of
type OCI_HTYPE_ERROR, not OCI_HTYPE_ENV
Problem 5 (minor suggestion):
Calls to OCIEnvInit, OCIHandleAlloc, OCIErrorGet & OCIHandleFree
in
php_oci_init_global_handles() could use PHP_OCI_CALL() so debug
trace
is generated.
Call to OCIInitialize in PHP_MINIT_FUNCTION() could use
PHP_OCI_CALL().
Call to OCITerminate in PHP_MSHUTDOWN_FUNCTION() could use
PHP_OCI_CALL().
A suggested patch is below. Please review and test as I may have
misunderstood the solutions for problems 3 and 5, or not have taken
care of some special cases.
I have been unable to verify the patch solves the problem because I
only see the problem on Windows, but can only build on Linux.
--- oci8.c.1.2832005-11-25 15:52:57.0 +1100
+++ oci8.c 2005-11-25 17:18:41.006806296 +1100
@@ -396,13 +396,13 @@
sb4 error_code = 0;
text tmp_buf[PHP_OCI_ERRBUF_LEN];
- errcode = OCIEnvInit (&OCI_G(env), OCI_DEFAULT, 0, NULL);
+ errcode = PHP_OCI_CALL(OCIEnvInit, (&OCI_G(env), OCI_DEFAULT, 0,
NULL));
if (errcode == OCI_ERROR) {
goto oci_error;
}
- errcode = OCIHandleAlloc (OCI_G(env), (dvoid **)&OCI_G(err),
OCI_HTYPE_ERROR, 0, NULL);
+ errcode = PHP_OCI_CALL(OCIHandleAlloc, (OCI_G(env), (dvoid
**)&OCI_G(err), OCI_HTYPE_ERROR, 0, NULL));
if (errcode == OCI_ERROR || errcode == OCI_SUCCESS_WITH_INFO) {
goto oci_error;
@@ -412,7 +412,7 @@
oci_error:
- OCIErrorGet(OCI_G(env), (ub4)1, NULL, &error_code, tmp_buf,
(ub4)PHP_OCI_ERRBUF_LEN, (ub4)OCI_HTYPE_ERROR);
+ PHP_OCI_CALL(OCIErrorGet, (OCI_G(env), (ub4)1, NULL, &error_code,
tmp_buf, (ub4)PHP_OCI_ERRBUF_LEN, (ub4)OCI_HTYPE_ERROR));
if (error_code) {
int tmp_buf_len = strlen(tmp_buf);
@@ -424,7 +424,7 @@
if (errcode != OCI_SUCCESS_WITH_INFO) {
php_error_docref(NULL TSRMLS_CC, E_WARNING, "OCI_ERROR: %s",
tmp_buf);
- OCIHandleFree((dvoid *) OCI_G(env), OCI_HTYPE_ENV);
+ PHP_OCI_CALL(OCIHandleFree, ((dvoid *) OCI_G(env),
OCI_HTYPE_ENV));
OCI_G(env) = NULL;
OCI_G(err) = NULL;
@@ -441,7 +441,7 @@
static void php_oci_cleanup_global_handles(TSRMLS_D)
{
if (OCI_G(err)) {
-PHP_OCI_CALL(OCIHandleFree, ((dvoid *) OCI_G(err),
OCI_HTYPE_ENV));
+PHP_OCI_CALL(OCIHandleFree, ((dvoid *) OCI_G(err),
OCI_HTYPE_ERROR));
OCI_G(err) = NULL;
}
@@ -480,7 +480,7 @@
#endif
#if !HAVE_OCI_ENV_CREATE
- OCIInitialize(PHP_OCI_INIT_MODE, NULL, NULL, NULL, NULL);
+ PHP_OCI_CALL(OCIInitialize, (PHP_OCI_INIT_MODE, NULL, NULL, NULL,
NULL));
#endif
ZEND_INIT_MODULE_GLOBALS(oci, php_oci_init_globals, NULL);
@@ -609,7 +609,7 @@
#endif
#if !HAVE_OCI_ENV_CREATE
- OCITerminate(OCI_DEFAULT);
+ PHP_OCI_CALL(OCITerminate, (OCI_DEFAULT));
#endif
return SUCCESS;
@@ -1408,10 +1408,18 @@
}
}
+ if (connection->svc && connection->session && connection->is_open)
{
+PHP_OCI_CALL(OCISessionEnd, (connection->svc, OCI_G(err),
connection->session, (ub4) 0));
+ }
+
if (connection->is_attached) {
PHP_OCI_CALL(OCIServerDetach, (connection->server, OCI_G(err),
OCI_DEFAULT));
}
+ if (connection->svc) {
+PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->svc, (ub4)
OCI_HTYPE_SVCCTX));
+ }
+
if (connection->err) {
PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->err, (ub4)
OCI_HTYPE_ERROR));
}
@@ -1424,23 +1432,15 @@
PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->server, (ub4)
OCI_HTYPE_SERVER));
}
- if (connection->svc) {
-if (connection->session && connection->is_open) {
- PHP_OCI_CALL(OCISessionEnd, (connection->svc, OCI_G(err),
connection->session, (ub4) 0));
-}
-
-PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->svc, (ub4)
OCI_HTYPE_SVCCTX));
- }
-
if (connection->env) {
PHP_OCI_CALL(OCIHandleFree, ((dvoid *) connection->env,
OCI_HTYPE_ENV));
}
if (connection->is_persistent) {
if (connecti
#35322 [Fbk->Opn]: oci_connect after oci_close gives unknown resource
ID: 35322
User updated by: cjbj at hotmail dot com
Reported By: cjbj at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: Linux
PHP Version: 5.0.5 & 5.1.0RC7
New Comment:
I have emailed Antony a little trace info.
Previous Comments:
[2005-11-22 13:24:00] [EMAIL PROTECTED]
Thanks.
That would be very much appreciated.
[2005-11-22 13:22:26] cjbj at hotmail dot com
Reproduced on Windows with 5.1.0RC7-dev (Nov 22 2005 08:23:50) with
matching OCI8 1.1 DLL. I'll check Linux tomorrow and see if I can get
some debug info.
[2005-11-22 11:52:29] [EMAIL PROTECTED]
Work fine here, with latest OCI8 from CVS.
[2005-11-22 09:15:24] [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-11-22 08:03:51] cjbj at hotmail dot com
Description:
The call sequence
oci_connect
oci_close
oci_connect
returns an unknown resource.
Reproduced on Linux with Zend Core for Oracle (PHP 5.0.5)
Reproduced on Windows with PHP 5.0.6-dev Nov 3 2005 18:23:25 using OCI8
1.1 php_oci.dll downloaded from
http://pecl4win.php.net/ext.php/php_oci8.dll on Nov 4.
The problem is possibly related to http://bugs.php.net/bug.php?id=35205
Reproduce code:
---
"; var_dump($user, $pass, $databaseName); echo "";
$conn = oci_connect( $user, $pass, $databaseName);
echo ""; var_dump($conn); echo "";
if (!$conn) {
echo "connection 1 failed";
exit;
}
oci_close($conn);
$conn = oci_connect( $user, $pass, $databaseName);
echo ""; var_dump($conn); echo "";
if (!$conn) {
echo "connection 2 failed";
exit;
}
oci_close($conn);
?>
Expected result:
string(2) "hr"
string(2) "hr"
string(14) "//localhost/XE"
resource(2) of type (oci8 connection)
resource(2) of type (oci8 connection)
Actual result:
--
string(2) "hr"
string(2) "hr"
string(14) "//localhost/XE"
resource(2) of type (oci8 connection)
resource(2) of type (Unknown)
Warning: oci_close(): 2 is not a valid oci8 connection resource in
/home/cj/public_html/php/t1.php on line 29
--
Edit this bug report at http://bugs.php.net/?id=35322&edit=1
#35329 [Fbk->Opn]: php.ini location breakage from 5.0
ID: 35329 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Windows XP PHP Version: 5.1.0RC6 New Comment: When I upgraded from 5.5 to 5.1, I had to 0. Unzip 5.1 to c:\php5-win32-latest 1. Edit c:/Program Files/Apache Group/Apache2/conf/httpd.conf and change: LoadModule php5_module "c:/php5.0-win32-200511031730/php5apache2.dll" to LoadModule php5_module "c:/php5-win32-latest/php5apache2.dll" 2. Edit c:\Program Files\Apache Group\Apache2\php.ini and change: extension_dir = "c:\php5.0-win32-200511031730\ext" to extension_dir = "c:\php5-win32-latest\ext" 3. Copy c:\Program Files\Apache Group\Apache2\php.ini to c:\WINDOWS Step 3 was not needed when upgrading any 5.0.x to 5.0.y. Previous Comments: [2005-11-23 01:33:12] [EMAIL PROTECTED] Did this path change: LoadModule php5_module "c:/php5-win32-latest/php5apache2.dll" -------------------- [2005-11-23 01:27:37] cjbj at hotmail dot com I am using Apache 1.3.33 and Apache 2.0.54. The only modifications in httpd.conf for PHP are: LoadModule php5_module "c:/php5-win32-latest/php5apache2.dll" AddType application/x-httpd-php .php AddType application/x-httpd-php .phtml AddType application/x-httpd-php-source .phps The paths I had php.ini at were: c:/Program Files/Apache Group/Apache2/php.ini and c:/Program Files/Apache Group/Apache/php.ini (Sorry about late night path-typos in the original report - I was trying not to get distracted from the bug I was trying to investigate.) Early in the 5.0 cycle I heard the search path for php.ini on Windows had changed. I have not been able to track down this original reference but http://www.php.net/manual/en/configuration.php#configuration.file does mention "The web server's directory" as being in the search path. Having php.ini in the Apache directory made it easy to upgrade PHP When I upgraded from 5.0.x to 5.0.y all I needed to do was unzip, editing the LoadModule command and update php.ini's extension_dir path. When I upgraded to 5.1 I had to move php.ini to c:\WINDOWS. Having a php.ini per web server made it easy to compare two configurations of PHP. Each ran under a different Apache. [2005-11-22 15:25:06] [EMAIL PROTECTED] And how exactly you have told in httpd.conf where PHP looks for php.ini? And what apache version is that? ---------------- [2005-11-22 13:10:42] cjbj at hotmail dot com Description: PHP 5.0 on Windows reads a php.ini located at c:/Program Files/Apache Group/Apache/conf/httpd.conf or c:/Program Files/Apache Group/Apache/conf2/httpd.conf. PHP 5.1.0RC7-dev (Nov 22 2005 08:23:50) does not read this php.ini. Phpinfo() shows php.ini as "C:\WINDOWS", i.e. it has not found a php.ini This is a backward compatibility breakage I didn't notice documented in Steph's 5.1 upgrade notes. -- Edit this bug report at http://bugs.php.net/?id=35329&edit=1
#35329 [Fbk->Opn]: php.ini location breakage from 5.0
ID: 35329 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com -Status: Feedback +Status: Open Bug Type: *General Issues Operating System: Windows XP PHP Version: 5.1.0RC6 New Comment: I am using Apache 1.3.33 and Apache 2.0.54. The only modifications in httpd.conf for PHP are: LoadModule php5_module "c:/php5-win32-latest/php5apache2.dll" AddType application/x-httpd-php .php AddType application/x-httpd-php .phtml AddType application/x-httpd-php-source .phps The paths I had php.ini at were: c:/Program Files/Apache Group/Apache2/php.ini and c:/Program Files/Apache Group/Apache/php.ini (Sorry about late night path-typos in the original report - I was trying not to get distracted from the bug I was trying to investigate.) Early in the 5.0 cycle I heard the search path for php.ini on Windows had changed. I have not been able to track down this original reference but http://www.php.net/manual/en/configuration.php#configuration.file does mention "The web server's directory" as being in the search path. Having php.ini in the Apache directory made it easy to upgrade PHP When I upgraded from 5.0.x to 5.0.y all I needed to do was unzip, editing the LoadModule command and update php.ini's extension_dir path. When I upgraded to 5.1 I had to move php.ini to c:\WINDOWS. Having a php.ini per web server made it easy to compare two configurations of PHP. Each ran under a different Apache. Previous Comments: [2005-11-22 15:25:06] [EMAIL PROTECTED] And how exactly you have told in httpd.conf where PHP looks for php.ini? And what apache version is that? ---- [2005-11-22 13:10:42] cjbj at hotmail dot com Description: PHP 5.0 on Windows reads a php.ini located at c:/Program Files/Apache Group/Apache/conf/httpd.conf or c:/Program Files/Apache Group/Apache/conf2/httpd.conf. PHP 5.1.0RC7-dev (Nov 22 2005 08:23:50) does not read this php.ini. Phpinfo() shows php.ini as "C:\WINDOWS", i.e. it has not found a php.ini This is a backward compatibility breakage I didn't notice documented in Steph's 5.1 upgrade notes. -- Edit this bug report at http://bugs.php.net/?id=35329&edit=1
#35322 [Fbk->Opn]: oci_connect after oci_close gives unknown resource
ID: 35322
User updated by: cjbj at hotmail dot com
Reported By: cjbj at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: Linux
-PHP Version: 5.0.5
+PHP Version: 5.0.5 & 5.1.0RC7
New Comment:
Reproduced on Windows with 5.1.0RC7-dev (Nov 22 2005 08:23:50) with
matching OCI8 1.1 DLL. I'll check Linux tomorrow and see if I can get
some debug info.
Previous Comments:
[2005-11-22 11:52:29] [EMAIL PROTECTED]
Work fine here, with latest OCI8 from CVS.
[2005-11-22 09:15:24] [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-11-22 08:03:51] cjbj at hotmail dot com
Description:
The call sequence
oci_connect
oci_close
oci_connect
returns an unknown resource.
Reproduced on Linux with Zend Core for Oracle (PHP 5.0.5)
Reproduced on Windows with PHP 5.0.6-dev Nov 3 2005 18:23:25 using OCI8
1.1 php_oci.dll downloaded from
http://pecl4win.php.net/ext.php/php_oci8.dll on Nov 4.
The problem is possibly related to http://bugs.php.net/bug.php?id=35205
Reproduce code:
---
"; var_dump($user, $pass, $databaseName); echo "";
$conn = oci_connect( $user, $pass, $databaseName);
echo ""; var_dump($conn); echo "";
if (!$conn) {
echo "connection 1 failed";
exit;
}
oci_close($conn);
$conn = oci_connect( $user, $pass, $databaseName);
echo ""; var_dump($conn); echo "";
if (!$conn) {
echo "connection 2 failed";
exit;
}
oci_close($conn);
?>
Expected result:
string(2) "hr"
string(2) "hr"
string(14) "//localhost/XE"
resource(2) of type (oci8 connection)
resource(2) of type (oci8 connection)
Actual result:
--
string(2) "hr"
string(2) "hr"
string(14) "//localhost/XE"
resource(2) of type (oci8 connection)
resource(2) of type (Unknown)
Warning: oci_close(): 2 is not a valid oci8 connection resource in
/home/cj/public_html/php/t1.php on line 29
--
Edit this bug report at http://bugs.php.net/?id=35322&edit=1
#35329 [NEW]: php.ini location breakage from 5.0
From: cjbj at hotmail dot com Operating system: Windows XP PHP version: 5.1.0RC6 PHP Bug Type: *General Issues Bug description: php.ini location breakage from 5.0 Description: PHP 5.0 on Windows reads a php.ini located at c:/Program Files/Apache Group/Apache/conf/httpd.conf or c:/Program Files/Apache Group/Apache/conf2/httpd.conf. PHP 5.1.0RC7-dev (Nov 22 2005 08:23:50) does not read this php.ini. Phpinfo() shows php.ini as "C:\WINDOWS", i.e. it has not found a php.ini This is a backward compatibility breakage I didn't notice documented in Steph's 5.1 upgrade notes. -- Edit bug report at http://bugs.php.net/?id=35329&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35329&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=35329&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=35329&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=35329&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=35329&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=35329&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=35329&r=needscript Try newer version: http://bugs.php.net/fix.php?id=35329&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=35329&r=support Expected behavior: http://bugs.php.net/fix.php?id=35329&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=35329&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=35329&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=35329&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35329&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=35329&r=dst IIS Stability: http://bugs.php.net/fix.php?id=35329&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=35329&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=35329&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=35329&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=35329&r=mysqlcfg
#35322 [NEW]: oci_connect after oci_close gives unknown resource
From: cjbj at hotmail dot com
Operating system: Linux
PHP version: 5.0.5
PHP Bug Type: OCI8 related
Bug description: oci_connect after oci_close gives unknown resource
Description:
The call sequence
oci_connect
oci_close
oci_connect
returns an unknown resource.
Reproduced on Linux with Zend Core for Oracle (PHP 5.0.5)
Reproduced on Windows with PHP 5.0.6-dev Nov 3 2005 18:23:25 using OCI8
1.1 php_oci.dll downloaded from
http://pecl4win.php.net/ext.php/php_oci8.dll on Nov 4.
The problem is possibly related to http://bugs.php.net/bug.php?id=35205
Reproduce code:
---
"; var_dump($user, $pass, $databaseName); echo "";
$conn = oci_connect( $user, $pass, $databaseName);
echo ""; var_dump($conn); echo "";
if (!$conn) {
echo "connection 1 failed";
exit;
}
oci_close($conn);
$conn = oci_connect( $user, $pass, $databaseName);
echo ""; var_dump($conn); echo "";
if (!$conn) {
echo "connection 2 failed";
exit;
}
oci_close($conn);
?>
Expected result:
string(2) "hr"
string(2) "hr"
string(14) "//localhost/XE"
resource(2) of type (oci8 connection)
resource(2) of type (oci8 connection)
Actual result:
--
string(2) "hr"
string(2) "hr"
string(14) "//localhost/XE"
resource(2) of type (oci8 connection)
resource(2) of type (Unknown)
Warning: oci_close(): 2 is not a valid oci8 connection resource in
/home/cj/public_html/php/t1.php on line 29
--
Edit bug report at http://bugs.php.net/?id=35322&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=35322&r=trysnapshot4
Try a CVS snapshot (php5.0):
http://bugs.php.net/fix.php?id=35322&r=trysnapshot50
Try a CVS snapshot (php5.1):
http://bugs.php.net/fix.php?id=35322&r=trysnapshot51
Fixed in CVS:http://bugs.php.net/fix.php?id=35322&r=fixedcvs
Fixed in release:http://bugs.php.net/fix.php?id=35322&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=35322&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=35322&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=35322&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=35322&r=support
Expected behavior: http://bugs.php.net/fix.php?id=35322&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=35322&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=35322&r=submittedtwice
register_globals:http://bugs.php.net/fix.php?id=35322&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=35322&r=php3
Daylight Savings:http://bugs.php.net/fix.php?id=35322&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=35322&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=35322&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=35322&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=35322&r=nozend
MySQL Configuration Error: http://bugs.php.net/fix.php?id=35322&r=mysqlcfg
#34653 [NEW]: No documentation for OCI-Lob->savefile and OCI-Lob->writetofile
From: cjbj at hotmail dot com Operating system: n/a PHP version: 6CVS-2005-09-27 (CVS) PHP Bug Type: OCI8 related Bug description: No documentation for OCI-Lob->savefile and OCI-Lob->writetofile Description: Documentation for OCI-Lob->savefile and OCI-Lob->writetofile is not in http://www.php.net/manual/en/ These methods are visible in the oci8.c file in CVS, http://www.php.net/manual/en/function.oci-new-descriptor.php OCI-Lob->savefile is also used in Example 1 of http://www.php.net/manual/en/function.oci-new-descriptor.php -- Edit bug report at http://bugs.php.net/?id=34653&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=34653&r=trysnapshot4 Try a CVS snapshot (php5.0): http://bugs.php.net/fix.php?id=34653&r=trysnapshot50 Try a CVS snapshot (php5.1): http://bugs.php.net/fix.php?id=34653&r=trysnapshot51 Fixed in CVS:http://bugs.php.net/fix.php?id=34653&r=fixedcvs Fixed in release:http://bugs.php.net/fix.php?id=34653&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=34653&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=34653&r=needscript Try newer version: http://bugs.php.net/fix.php?id=34653&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=34653&r=support Expected behavior: http://bugs.php.net/fix.php?id=34653&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=34653&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=34653&r=submittedtwice register_globals:http://bugs.php.net/fix.php?id=34653&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=34653&r=php3 Daylight Savings:http://bugs.php.net/fix.php?id=34653&r=dst IIS Stability: http://bugs.php.net/fix.php?id=34653&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=34653&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=34653&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=34653&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=34653&r=mysqlcfg
#34607 [Com]: oci_bind_by_name fails when $variable has NULL value
ID: 34607
Comment by: cjbj at hotmail dot com
Reported By: robcolbert at yahoo dot com
Status: Open
Bug Type: OCI8 related
Operating System: Fedora Core 4
PHP Version: 5.0.5
New Comment:
I was just about to log a similar bug. Here is my testcase:
array(0) {
}
}
*/
define('ORA_CON_UN', 'hr');
define('ORA_CON_PW', 'hr');
define('ORA_CON_DB', '//localhost/orcl');
$statement = "select * from dual where dummy = :mybv";
$conn = oci_connect(ORA_CON_UN, ORA_CON_PW, ORA_CON_DB);
$stid = oci_parse($conn, $statement);
$r = oci_bind_by_name($stid, ":mybv", $undef, $undef2);
$r = oci_execute($stid, OCI_DEFAULT);
$r = oci_fetch_all($stid, $results);
echo ""; var_dump($results); echo "";
?>
Previous Comments:
[2005-09-23 05:44:12] robcolbert at yahoo dot com
Description:
It is not possible to use oci_bind_by_name to assign a NULL value to a
placeholder. The OCI will attempt to allocate a very large (negative)
amount of memory and cause the script to exit due to memory depletion.
I'm not sure if this is a bug or intended behavior, but it was
frustrating to figure out, and limits the programmer's ability to use a
truly generic statement for all cases. I have found myself having to
code constructs such as:
if( $SomeVarB == NULL )
{
$SQL = "INSERT INTO table (a, b) VALUES (:a, NULL)";
$stid = $oci_parse($conn, $SQL);
oci_bind_by_name($stid, ":a", $SomeVarA);
}
else
{
$SQL = "INSERT INTO table (a, b) VALUES (:a, :b)";
$stid = $oci_parse($conn, $SQL);
oci_bind_by_name($stid, ":a", $SomeVarA);
oci_bind_by_name($stid, ":b", $SomeVarB);
}
This is bloating scripts unnecessarily, and I expect that other
programmers are experiencing similar results. It would be better if
NULL could be specified as the input variable value to mean that the
OCI should use NULL for the given placeholder's value such as:
$SomeVarB = NULL;
oci_bind_by_name($stid, ":b", $SomeVarB);
Reproduce code:
---
$SomeVarB = NULL;
oci_bind_by_name($stid, ":placeholder", $SomeVarB);
Expected result:
The OCI should use the NULL SQL value supplied as the value of the
$variable input parameter. The OCI should attempt to allocate an
enormous amount of memory and cause the script to terminate.
If NULL cannot be handled as an input $variable value, then it is
expected for the API to return an error code and allow the application
to handle the error rather than causing an abortive condition (script
termination) to occur.
Actual result:
--
PHP Fatal error: Allowed memory size of 8388608 bytes exhausted (tried
to allocate -153092209 bytes).
--
Edit this bug report at http://bugs.php.net/?id=34607&edit=1
#31084 [NEW]: Suggested config.m4 changes to compile with Oracle OCI8 Instant Client
From: cjbj at hotmail dot com Operating system: Linux PHP version: 4.3.9 PHP Bug Type: OCI8 related Bug description: Suggested config.m4 changes to compile with Oracle OCI8 Instant Client Description: This is a suggested enhancement for PHP's ext/oci8/config.m4 to enable PHP to be built with the Oracle Instant Client 10.1 libraries and SDK. This allows PHP to connect to an existing, remote Oracle DB without needing a full install of Oracle. The diff adds a new configuration parameter --with-oci8-instant-client[=DIR] that takes the directory of the Oracle Instant Client libraries. It is the solution previously discussed with Antony. The new "--with-oci8-instant-client" and existing "--with-oci8" options are mutually exclusive. Instructions: Install the Instant Client "basic" and "SDK" packages from Oracle: http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html Make sure a symbolic link exists from libclntsh.so pointing to libclntsh.so.10.1. If the Linux RPMs were installed then this is automatically created. Backup and apply the diff listed below to ext/oci8/config.m4 cd php-4.3.9 rm -rf autom4te.cache config.cache ./buildconf --force Run configure. These are the options I needed to use to install PHP 4.3.9 on my local Apache under Redhat 3: ./configure \ --with-oci8-instant-client=/usr/lib/oracle/10.1.0.3/client/lib \ --prefix=$HOME/php --with-apxs=$HOME/apache/bin/apxs \ --enable-sigchild --with-config-file-path=$HOME/apache/conf (Since I was on linux I could have used --with-oci8-instant-client without giving a directory) make install You might need to set LD_LIBRARY_PATH to /usr/lib/oracle/10.1.0.3/client/lib before starting Apache. If a connection string is needed, also set TNS_ADMIN. For Oracle-standard connection information see section 1.3 of http://www.oracle.com/technology/docs/tech/sql_plus/10103/readme_ic.htm Note: these changes have only been tested on Linux using the Oracle Instant Client 10.1.0.3 release and PHP 4.3.9. --- ext/oci8/config.m4.orig 2004-02-04 01:22:34.0 +1100 +++ ext/oci8/config.m4 2004-12-14 18:36:21.0 +1100 @@ -38,16 +38,46 @@ OCI8_VERSION=8.1 fi else -AC_MSG_ERROR(Oracle-OCI8 needed libraries not found) +AC_MSG_ERROR([Oracle (OCI8) required libraries not found]) fi AC_MSG_RESULT($OCI8_VERSION) ]) -PHP_ARG_WITH(oci8, for Oracle-OCI8 support, -[ --with-oci8[=DIR] Include Oracle-oci8 support. Default DIR is ORACLE_HOME.]) +AC_DEFUN(AC_OCI8IC_VERSION,[ + AC_MSG_CHECKING([Oracle Instant Client version]) + if test -f $PHP_OCI8_INSTANT_CLIENT/libociei.$SHLIB_SUFFIX_NAME; then +if test -f $PHP_OCI8_INSTANT_CLIENT/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then + if test ! -f $PHP_OCI8_INSTANT_CLIENT/libclntsh.$SHLIB_SUFFIX_NAME; then +AC_MSG_ERROR([Link from $PHP_OCI8_INSTANT_CLIENT/libclntsh.$SHLIB_SUFFIX_NAME to libclntsh.$SHLIB_SUFFIX_NAME.10.1 not found]) + fi + OCI8_VERSION=10.1 +else + AC_MSG_ERROR([Oracle Instant Client library version not supported]) +fi + else +AC_MSG_ERROR([Oracle Instant Client libraries not found]) + fi + AC_MSG_RESULT([$OCI8_VERSION]) +]) + +PHP_ARG_WITH(oci8, for Oracle (OCI8) support using ORACLE_HOME installation, +[ --with-oci8[[=DIR]] Include Oracle (OCI8) support using an ORACLE_HOME +install. The default DIR is ORACLE_HOME]) + +PHP_ARG_WITH(oci8-instant-client, for Oracle (OCI8) support using Oracle Instant Client, +[ --with-oci8-instant-client[[=DIR]]Include Oracle (OCI8) support using +Oracle Instant Client. DIR is the directory with the +Instant Client libraries. On Linux it will default to +/usr/lib/oracle//client/lib +Other platforms will need to have it explicitly specified.]) if test "$PHP_OCI8" != "no"; then - AC_MSG_CHECKING([Oracle Install-Dir]) + + if test "$PHP_OCI8_INSTANT_CLIENT" != "no"; then +AC_MSG_ERROR([--with-oci8 and --with-oci8-instant-client are mutually exclusive]) + fi + + AC_MSG_CHECKING([Oracle Install Directory]) if test "$PHP_OCI8" = "yes"; then OCI8_DIR=$ORACLE_HOME else @@ -116,14 +146,18 @@ -L$OCI8_DIR/lib $OCI8_SHARED_LIBADD ]) ;; + 10.1) PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) AC_DEFINE(HAVE_OCI_9_2,1,[ ]) + AC_DEFINE(HAVE_OCI8_TEMP_LOB,1,[ ]) + AC_DEFINE(PHP_OCI8_HAVE_COLLECTIONS,1,[ ])
#31084 [Opn]: Suggested config.m4 changes to compile with Oracle OCI8 Instant Client
ID: 31084 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com Status: Open Bug Type: OCI8 related Operating System: Linux PHP Version: 4.3.9 New Comment: To see an unmunged copy of the diff, go to http://forums.oracle.com/forums/thread.jsp?nav=false&forum=178&thread=279365 Previous Comments: [2004-12-14 09:16:28] cjbj at hotmail dot com Description: This is a suggested enhancement for PHP's ext/oci8/config.m4 to enable PHP to be built with the Oracle Instant Client 10.1 libraries and SDK. This allows PHP to connect to an existing, remote Oracle DB without needing a full install of Oracle. The diff adds a new configuration parameter --with-oci8-instant-client[=DIR] that takes the directory of the Oracle Instant Client libraries. It is the solution previously discussed with Antony. The new "--with-oci8-instant-client" and existing "--with-oci8" options are mutually exclusive. Instructions: Install the Instant Client "basic" and "SDK" packages from Oracle: http://www.oracle.com/technology/tech/oci/instantclient/instantclient.html Make sure a symbolic link exists from libclntsh.so pointing to libclntsh.so.10.1. If the Linux RPMs were installed then this is automatically created. Backup and apply the diff listed below to ext/oci8/config.m4 cd php-4.3.9 rm -rf autom4te.cache config.cache ./buildconf --force Run configure. These are the options I needed to use to install PHP 4.3.9 on my local Apache under Redhat 3: ./configure \ --with-oci8-instant-client=/usr/lib/oracle/10.1.0.3/client/lib \ --prefix=$HOME/php --with-apxs=$HOME/apache/bin/apxs \ --enable-sigchild --with-config-file-path=$HOME/apache/conf (Since I was on linux I could have used --with-oci8-instant-client without giving a directory) make install You might need to set LD_LIBRARY_PATH to /usr/lib/oracle/10.1.0.3/client/lib before starting Apache. If a connection string is needed, also set TNS_ADMIN. For Oracle-standard connection information see section 1.3 of http://www.oracle.com/technology/docs/tech/sql_plus/10103/readme_ic.htm Note: these changes have only been tested on Linux using the Oracle Instant Client 10.1.0.3 release and PHP 4.3.9. --- ext/oci8/config.m4.orig 2004-02-04 01:22:34.0 +1100 +++ ext/oci8/config.m4 2004-12-14 18:36:21.0 +1100 @@ -38,16 +38,46 @@ OCI8_VERSION=8.1 fi else -AC_MSG_ERROR(Oracle-OCI8 needed libraries not found) +AC_MSG_ERROR([Oracle (OCI8) required libraries not found]) fi AC_MSG_RESULT($OCI8_VERSION) ]) -PHP_ARG_WITH(oci8, for Oracle-OCI8 support, -[ --with-oci8[=DIR] Include Oracle-oci8 support. Default DIR is ORACLE_HOME.]) +AC_DEFUN(AC_OCI8IC_VERSION,[ + AC_MSG_CHECKING([Oracle Instant Client version]) + if test -f $PHP_OCI8_INSTANT_CLIENT/libociei.$SHLIB_SUFFIX_NAME; then +if test -f $PHP_OCI8_INSTANT_CLIENT/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then + if test ! -f $PHP_OCI8_INSTANT_CLIENT/libclntsh.$SHLIB_SUFFIX_NAME; then +AC_MSG_ERROR([Link from $PHP_OCI8_INSTANT_CLIENT/libclntsh.$SHLIB_SUFFIX_NAME to libclntsh.$SHLIB_SUFFIX_NAME.10.1 not found]) + fi + OCI8_VERSION=10.1 +else + AC_MSG_ERROR([Oracle Instant Client library version not supported]) +fi + else +AC_MSG_ERROR([Oracle Instant Client libraries not found]) + fi + AC_MSG_RESULT([$OCI8_VERSION]) +]) + +PHP_ARG_WITH(oci8, for Oracle (OCI8) support using ORACLE_HOME installation, +[ --with-oci8[[=DIR]] Include Oracle (OCI8) support using an ORACLE_HOME +install. The default DIR is ORACLE_HOME]) + +PHP_ARG_WITH(oci8-instant-client, for Oracle (OCI8) support using Oracle Instant Client, +[ --with-oci8-instant-client[[=DIR]]Include Oracle (OCI8) support using +Oracle Instant Client. DIR is the directory with the +Instant Client libraries. On Linux it will default to + /usr/lib/oracle//client/lib +Other platforms will need to have it explicitly specified.]) if test "$PHP_OCI8" != "no"; then - AC_MSG_CHECKING([Oracle Install-Dir]) + + if test "$PHP_OCI8_INSTANT_CLIENT" != "no"; then +AC_MSG_ERROR([--with-oci8 and --with-oci8-instant-client are mutually exclusive]) + fi + + AC_MSG_CHECKING([Oracle Install Directory]) if test "$PHP_OCI8" = "yes"; then OCI8_DIR=$ORACLE_HOME else @@ -116,14 +146,18 @@ -L$OCI8_DIR/lib $OCI8_SHARED_LIBADD ]) ;; + 10.
#29013 [Fbk->Opn]: Multiple logons cause handles to become invalid
ID: 29013
User updated by: cjbj at hotmail dot com
Reported By: cjbj at hotmail dot com
-Status: Feedback
+Status: Open
Bug Type: OCI8 related
-Operating System: Windows, Linus
+Operating System: Windows, Linux
PHP Version: 4.3.7, 5.0.0 Dev
Assigned To: tony2001
New Comment:
Using one user would make it harder to demonstrate the
problem. Sorry I didn't include create user scripts etc.
I retested with 4.3.10-dev and 5.0.3-dev binaries of a few
minutes ago. I am using W2K with Oracle 9.2 client libraries.
I am still seeing the usernames printed as SCOTT and HR,
which is "incorrect".
Previous Comments:
[2004-10-12 07:20:03] [EMAIL PROTECTED]
No, of course you should able to connect to Oracle from PHP using
different logins.
My question should be read in this way: "are you able to reproduce it
under 1 user, but with different connections, because I was too lazy to
create a new user in Oracle?".
Btw, I've already created additional user and tested your code - your
example works perfectly for me.
----
[2004-10-12 05:38:56] cjbj at hotmail dot com
The "business requirement" comes from the original report in
http://forums.oracle.com/forums/thread.jsp?forum=178&thread=251141
I don't think the way $c1 is impacted by the second login is obvious
or nice behavior.
I feel the problem is related to some of the common OCI8 connection
issues due to the caching and reuse of handles. It would be nice to
resolve these issues.
There is no Oracle-OCI reason why two users can't be connected at one
time. I think it should be allowed in PHP. But if you think the
PHP-OCI8 interface should not support concurrent connections, can a
PHP error be generated at the time of the second OCINLogin()?
[2004-10-10 17:02:43] [EMAIL PROTECTED]
Chris, is it important to have different users in your example?
Tested under 1 user (but using ociNlogin();) and it works fine.
--------------------
[2004-08-13 05:32:39] cjbj at hotmail dot com
The given testcase has an extra semi-colon in the second query. The
new testcase below shows that the initial connection is getting
associated with the second user.
Testcase:
";
$rSth = OCIParse($c, $s);
$rRet = OCIExecute($rSth);
echo "";
while ($succ = OCIFetchInto($rSth, $row)) {
foreach ($row as $item) {
echo ($item?htmlentities($item):' ')." ";
}
echo "\n";
}
echo "===>CLOSE";
ocifreestatement($rSth);
}
$statement1 = "select user from dual";
echo "===>OCINLogin #1: Connect as SCOTT";
$c1 = OCINlogon('scott', 'tiger', 'F10D' );
echo "===>Query first connection";
qry($c1, $statement1);
echo "===>OCINLogin #2: Connect as HR";
$c2 = OCINlogon('hr', 'hr', 'F10D');
echo "===>Re-query first connection";
qry($c1, $statement1);
?>
Actual Output:
===>OCINLogin #1: Connect as SCOTT
===>Query first connection
===>BEGIN
SCOTT
===>CLOSE
===>OCINLogin #2: Connect as HR
===>Re-query first connection
===>BEGIN
HR
===>CLOSE
Expected output is similar with the usernames in this order: SCOTT,
SCOTT
[2004-07-05 09:38:01] cjbj at hotmail dot com
Description:
Multiple logons within the same request cause handles to become invalid
and queries to fail.
Also see:
http://forums.oracle.com/forums/thread.jsp?forum=178&thread=251141
To reproduce, restart Apache and run the following file.
The same incorrect output occurs with ocilogon() inplace of
ocinlogon().
Reproduce code:
---
===>BEGIN";
$rSth = OCIParse($c, $s);
$rRet = OCIExecute($rSth);
echo "";
while ($succ = OCIFetchInto($rSth, $row)) {
foreach ($row as $item) {
echo ($item?htmlentities($item):' ')." ";
}
echo "\n";
}
echo "===>CLOSE";
ocifreestatement($rSth);
}
$statement1 = "select dname from dept";
$statement2 = "select user from dual;";
echo "===>OCINLogin #1";
$c1 = OCINlogon('scott', 'tiger', 'MYDB' );
echo "===>Query first connection";
qry($c1, $statement1);
echo "===>OCINLogin #2";
$c2 = OCINlogon('hr', 'hr', 'MYDB');
echo "===>Re-query first connection"
#29013 [->Opn]: Multiple logons cause handles to become invalid
ID: 29013
User updated by: cjbj at hotmail dot com
Reported By: cjbj at hotmail dot com
-Status:
+Status: Open
Bug Type: OCI8 related
Operating System: Windows, Linus
PHP Version: 4.3.7, 5.0.0 Dev
Assigned To: tony2001
New Comment:
The "business requirement" comes from the original report in
http://forums.oracle.com/forums/thread.jsp?forum=178&thread=251141
I don't think the way $c1 is impacted by the second login is obvious
or nice behavior.
I feel the problem is related to some of the common OCI8 connection
issues due to the caching and reuse of handles. It would be nice to
resolve these issues.
There is no Oracle-OCI reason why two users can't be connected at one
time. I think it should be allowed in PHP. But if you think the
PHP-OCI8 interface should not support concurrent connections, can a
PHP error be generated at the time of the second OCINLogin()?
Previous Comments:
[2004-10-10 17:02:43] [EMAIL PROTECTED]
Chris, is it important to have different users in your example?
Tested under 1 user (but using ociNlogin();) and it works fine.
[2004-08-13 05:32:39] cjbj at hotmail dot com
The given testcase has an extra semi-colon in the second query. The
new testcase below shows that the initial connection is getting
associated with the second user.
Testcase:
";
$rSth = OCIParse($c, $s);
$rRet = OCIExecute($rSth);
echo "";
while ($succ = OCIFetchInto($rSth, $row)) {
foreach ($row as $item) {
echo ($item?htmlentities($item):' ')." ";
}
echo "\n";
}
echo "===>CLOSE";
ocifreestatement($rSth);
}
$statement1 = "select user from dual";
echo "===>OCINLogin #1: Connect as SCOTT";
$c1 = OCINlogon('scott', 'tiger', 'F10D' );
echo "===>Query first connection";
qry($c1, $statement1);
echo "===>OCINLogin #2: Connect as HR";
$c2 = OCINlogon('hr', 'hr', 'F10D');
echo "===>Re-query first connection";
qry($c1, $statement1);
?>
Actual Output:
===>OCINLogin #1: Connect as SCOTT
===>Query first connection
===>BEGIN
SCOTT
===>CLOSE
===>OCINLogin #2: Connect as HR
===>Re-query first connection
===>BEGIN
HR
===>CLOSE
Expected output is similar with the usernames in this order: SCOTT,
SCOTT
[2004-07-05 09:38:01] cjbj at hotmail dot com
Description:
Multiple logons within the same request cause handles to become invalid
and queries to fail.
Also see:
http://forums.oracle.com/forums/thread.jsp?forum=178&thread=251141
To reproduce, restart Apache and run the following file.
The same incorrect output occurs with ocilogon() inplace of
ocinlogon().
Reproduce code:
---
===>BEGIN";
$rSth = OCIParse($c, $s);
$rRet = OCIExecute($rSth);
echo "";
while ($succ = OCIFetchInto($rSth, $row)) {
foreach ($row as $item) {
echo ($item?htmlentities($item):' ')." ";
}
echo "\n";
}
echo "===>CLOSE";
ocifreestatement($rSth);
}
$statement1 = "select dname from dept";
$statement2 = "select user from dual;";
echo "===>OCINLogin #1";
$c1 = OCINlogon('scott', 'tiger', 'MYDB' );
echo "===>Query first connection";
qry($c1, $statement1);
echo "===>OCINLogin #2";
$c2 = OCINlogon('hr', 'hr', 'MYDB');
echo "===>Re-query first connection";
qry($c1, $statement1);
echo "===>Re-query first connection";
qry($c1, $statement2);
?>
Expected result:
Three queries are successfully completed.
Actual result:
--
===>OCINLogin #1
OCIDebug: _oci_open_server new conn=0 dname=MYDB
OCIDebug: _oci_open_session new sess=3 user=scott
OCIDebug: oci_do_connect: id=4
===>Query first connection
===>BEGIN
OCIDebug: oci_parse "select dname from dept" id=5 conn=4
ACCOUNTING
RESEARCH
SALES
OPERATIONS
===>CLOSE
OCIDebug: START _oci_stmt_list_dtor: id=5 last_query="select dname
from dept"
OCIDebug: START _oci_column_hash_dtor: DNAME
OCIDebug: END _oci_column_hash_dtor: DNAME
OCIDebug: END _oci_stmt_list_dtor: id=5
===>OCINLogin #2
OCIDebug: _oci_open_session new sess=6 user=hr
OCIDebug: oci_do_connect: id=7
===>Re-query first connection
===>BEGIN
OCIDebug: oci_parse "select dname
#30401 [Com]: connectivity to oci through apache
ID: 30401 Comment by: cjbj at hotmail dot com Reported By: aazizi at comcast dot net Status: Open Bug Type: Oracle related Operating System: Linux EL 30 PHP Version: 4.3.9 New Comment: This report does not have enough information to qualify as a bug. A good place to post the problem is to the php.db mail list, i.e. http://news.php.net/group.php?group=php.db Before doing that read: http://www.oracle.com/technology/tech/opensource/php/php_troubleshooting_faq.html and check your Apache and PHP environment variables. Previous Comments: [2004-10-11 19:51:25] aazizi at comcast dot net Description: I have tried and experience the following problem on three different systems. I have apache 2 + php + oracle8i client This is my test script called oradbinfo.php: from the command line when I run: php oradbinfo.php I get: Successfully connected to Oracle. However, when I brows the page through http browser, I get: Fatal error: Call to undefined function: ocilogon() in /var/www/html/test.php on line 2 any clues, -thanx -- Edit this bug report at http://bugs.php.net/?id=30401&edit=1
#29013 [Opn]: Multiple logons cause handles to become invalid
ID: 29013
User updated by: cjbj at hotmail dot com
Reported By: cjbj at hotmail dot com
Status: Open
Bug Type: OCI8 related
-Operating System: Windows 2000
+Operating System: Windows, Linus
-PHP Version: 4.3.7
+PHP Version: 4.3.7, 5.0.0 Dev
New Comment:
The given testcase has an extra semi-colon in the second query. The
new testcase below shows that the initial connection is getting
associated with the second user.
Testcase:
";
$rSth = OCIParse($c, $s);
$rRet = OCIExecute($rSth);
echo "";
while ($succ = OCIFetchInto($rSth, $row)) {
foreach ($row as $item) {
echo ($item?htmlentities($item):' ')." ";
}
echo "\n";
}
echo "===>CLOSE";
ocifreestatement($rSth);
}
$statement1 = "select user from dual";
echo "===>OCINLogin #1: Connect as SCOTT";
$c1 = OCINlogon('scott', 'tiger', 'F10D' );
echo "===>Query first connection";
qry($c1, $statement1);
echo "===>OCINLogin #2: Connect as HR";
$c2 = OCINlogon('hr', 'hr', 'F10D');
echo "===>Re-query first connection";
qry($c1, $statement1);
?>
Actual Output:
===>OCINLogin #1: Connect as SCOTT
===>Query first connection
===>BEGIN
SCOTT
===>CLOSE
===>OCINLogin #2: Connect as HR
===>Re-query first connection
===>BEGIN
HR
===>CLOSE
Expected output is similar with the usernames in this order: SCOTT,
SCOTT
Previous Comments:
[2004-07-05 09:38:01] cjbj at hotmail dot com
Description:
Multiple logons within the same request cause handles to become invalid
and queries to fail.
Also see:
http://forums.oracle.com/forums/thread.jsp?forum=178&thread=251141
To reproduce, restart Apache and run the following file.
The same incorrect output occurs with ocilogon() inplace of
ocinlogon().
Reproduce code:
---
===>BEGIN";
$rSth = OCIParse($c, $s);
$rRet = OCIExecute($rSth);
echo "";
while ($succ = OCIFetchInto($rSth, $row)) {
foreach ($row as $item) {
echo ($item?htmlentities($item):' ')." ";
}
echo "\n";
}
echo "===>CLOSE";
ocifreestatement($rSth);
}
$statement1 = "select dname from dept";
$statement2 = "select user from dual;";
echo "===>OCINLogin #1";
$c1 = OCINlogon('scott', 'tiger', 'MYDB' );
echo "===>Query first connection";
qry($c1, $statement1);
echo "===>OCINLogin #2";
$c2 = OCINlogon('hr', 'hr', 'MYDB');
echo "===>Re-query first connection";
qry($c1, $statement1);
echo "===>Re-query first connection";
qry($c1, $statement2);
?>
Expected result:
Three queries are successfully completed.
Actual result:
--
===>OCINLogin #1
OCIDebug: _oci_open_server new conn=0 dname=MYDB
OCIDebug: _oci_open_session new sess=3 user=scott
OCIDebug: oci_do_connect: id=4
===>Query first connection
===>BEGIN
OCIDebug: oci_parse "select dname from dept" id=5 conn=4
ACCOUNTING
RESEARCH
SALES
OPERATIONS
===>CLOSE
OCIDebug: START _oci_stmt_list_dtor: id=5 last_query="select dname
from dept"
OCIDebug: START _oci_column_hash_dtor: DNAME
OCIDebug: END _oci_column_hash_dtor: DNAME
OCIDebug: END _oci_stmt_list_dtor: id=5
===>OCINLogin #2
OCIDebug: _oci_open_session new sess=6 user=hr
OCIDebug: oci_do_connect: id=7
===>Re-query first connection
===>BEGIN
OCIDebug: oci_parse "select dname from dept" id=8 conn=4
Warning: ociexecute(): OCIStmtExecute: ORA-00942: table or view does
not exist in c:\cj\php\cj\contest.php on line 13
Warning: ocifetchinto(): OCIFetchInto: ORA-24374: define not done
before fetch or execute and fetch in c:\cj\php\cj\contest.php on line
15
===>CLOSE
OCIDebug: START _oci_stmt_list_dtor: id=8 last_query="select dname
from dept"
OCIDebug: END _oci_stmt_list_dtor: id=8
===>Re-query first connection
===>BEGIN
OCIDebug: oci_parse "select user from dual;" id=9 conn=4
Warning: ociexecute(): OCIStmtExecute: ORA-00911: invalid character
in c:\cj\php\cj\contest.php on line 13
Warning: ocifetchinto(): OCIFetchInto: ORA-24374: define not done
before fetch or execute and fetch in c:\cj\php\cj\contest.php on line
15
===>CLOSE
OCIDebug: START _oci_stmt_list_dtor: id=9 last_query="select user
from dual;"
OCIDebug: END _oci_stmt_list_dtor: id=9
OCIDebug: START php_rshutdown_oci
OCIDebug: END php_rshu
#29624 [Com]: OCINlsEnvironmentVariableGet: referenced symbol not found
ID: 29624 Comment by: cjbj at hotmail dot com Reported By: dmarek1 at att dot net Status: Open Bug Type: OCI8 related Operating System: Solaris 2.8 PHP Version: 5.0.0 New Comment: I guess at runtime you're using the Oracle DB libraries that came with iAS. These are probably older than the DB environment you built with. Try building with the ORACLE_HOME that you are running with. See http://www.oracle.com/technology/products/ias/ohs/htdocs/php_ohs.htm Previous Comments: [2004-08-12 03:01:09] dmarek1 at att dot net Description: I am okay to build oci8 with PHP 5 and the make is okay but when I start http server the error below occurs. I have iAS 10g for one home with a 9.2 client on another. I build oci8 to 9.2 home and all other to 10G iAS. Without oci8 all is good and the server runs and handles PHP but with oci8 I can't go on. Thanks for any help /opt/oracle/product/TCLB/iAS/Apache/Apache/bin/apachectl start: execing httpd Syntax error on line 232 of /opt/oracle/product/TCLB/iAS/Apache/Apache/conf/httpd.conf: Cannot load /opt/oracle/product/TCLB/iAS/Apache/Apache/libexec/libphp5.so into server: ld.so.1: /opt/oracle/product/TCLB/i AS/Apache/Apache/bin/httpd: fatal: relocation error: file /opt/oracle/product/TCLB/iAS/Apache/Apache/libexec/libphp5.so: s ymbol OCINlsEnvironmentVariableGet: referenced symbol not found Reproduce code: --- ./configure --with-oci8=/opt/oracle/product/TCLB/9.2.C --with-gd=/usr/local --with-jpeg-dir=/usr/local --with-png-dir=/usr /local --with-zlib-dir=/usr/local --with-xpm-dir=/usr/local --with-ttf=/usr/local --with-freetype-dir=/usr/local --enable- gd-native-ttf --with-mysql=/usr/local/mysql --with-apxs=/opt/oracle/product/TCLB/iAS/Apache/Apache/bin/apxs --prefix=/opt/ oracle/product/TCLB/iAS --with-config-file-path=/opt/oracle/product/TCLB/iAS/Apache/Apache/conf Expected result: Server starts and oci calls work! Actual result: -- Can't start server as error above shows. -- Edit this bug report at http://bugs.php.net/?id=29624&edit=1
#29444 [Com]: Crash attemping to connect Oracle via oci8 when database is not mounted
ID: 29444
Comment by: cjbj at hotmail dot com
Reported By: oguilloux at sopragroup dot com
Status: Open
Bug Type: OCI8 related
Operating System: Windows 2000 SP4
PHP Version: 5.0.0
New Comment:
Can the filer give a better testcase? Does the DB have to
be unmounted? Does ADOdb have to be used?
Previous Comments:
[2004-07-29 17:53:44] oguilloux at sopragroup dot com
There's a strange stuff : If I only use, the function oci8 "oci_logon"
even if the database is not connected, it's works. But when I combine
pure oci8 functions with ADO-DB (http://php.weblogs.com) for PHP (which
is useful to be database independant).
I use the "version V3.00 6 Jan 2003" of PHP AdoDB. May be, with the new
Object feature, it could be create some problems ? The most strange
thing is that "oracle" functions work good.
I have tested the AdoDB 4.51 for PHP, but PHP still crash.
[2004-07-29 16:01:25] [EMAIL PROTECTED]
Yes, probably other suggestions will appear when I can reproduce it
myself.
ATM I can see only predictable warning and nothing more.
[2004-07-29 15:33:25] oguilloux at sopragroup dot com
Thank's !
sorry, but why it works with oci8/PHP4 and not with oci8/PHP5 ? I don't
believe that the cause is my Oracle client. I often do EXP, IMP and
SQLPLUS with my oracle 8 on oracle 9 database without any troubles.
I restore my config to works with PHP4/oci8 and my web site works
without any problem. The only change was to reconfig apache to use
PHP4.
The more strange feature is that PHP5/oracle extention works better
than oci8.
Have you another suggestion to try ?
Thank's !
[2004-07-29 15:24:30] [EMAIL PROTECTED]
>My oracle client is 8.1.7 and I wish connected to a Oracle 9.2.0.4
database.
That's weird and can be the reason.
Try to update your client - I can't reproduce this under WIn2k, Oracle
9.2.0.4/Client 9.2.0.4.
[2004-07-29 15:12:59] oguilloux at sopragroup dot com
Description:
Using oci8 extention for connecting Oracle Database crash PHP (with and
without Apache) when SID isn't found.
I'm working with PHP 5 (13 july version), Win 2K SP4. My oracle client
is 8.1.7 and I wish connected to a Oracle 9.2.0.4 database. In PHP4, I
had no problems in oci8, but now, PHP crash.
The SOLUTION is to use oracle extention which work even if database has
some trouble.
In my PHP.INI, I use :
extension=php_gd2.dll
extension=php_oracle.dll
extension=php_oci8.dll
extension=php_sockets.dll
extension=php_mbstring.dll
extension=php_zip.dll
Reproduce code:
---
$argDatabasename = 'PNGRS24';
$cn = OCILogon('SYSTEM','MANAGER',
"(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=RS24.PA.SOPRA)(PORT=1542))(CONNECT_DATA=(SID=$argDatabasename)))");
// BUT with ORACLE_LOGON() (not oci8) it's work !
Expected result:
That oci8 does work as well as oracle extention in PHP 5
Actual result:
--
(IN EVENTVIEWER, WITH LOG IN SYSINFO)
FOR APACHE 1.3.29 / PHP5
Application popup : apache.exe - Erreur d'application : L'instruction à
"0x01822456" emploie l'adresse memoire "0x0008". La memoire ne peut
pas etre "read".
WITH PHP5 logs
--
PHP Warning: ociplogon() [function.ociplogon]: _oci_open_server:
ORA-12514: TNS : le listener n'a pas pu resoudre le SERVICE_NAME
figurant dans le descripteur de connexion in c:\work\WEB\LookSGBD.php
on line 31.
IN DEBUGGER
---
My debugger tell me that it's crashed on php_oci8.dll at this code line
(stack):
01492456 cmp dword ptr [eax+8],2
--
Edit this bug report at http://bugs.php.net/?id=29444&edit=1
#28948 [Com]: Solaris - IPlanet - Initialized PHP Module frequently
ID: 28948 Comment by: cjbj at hotmail dot com Reported By: christian dot gottschalch at is-energy dot de Status: Open Bug Type: OCI8 related Operating System: Solaris 5.8 PHP Version: 4.3.7 New Comment: What's the exact version of the Oracle client libraries? Your stack traces show crashes deep within Oracle code. I think you should contact Oracle Support. Previous Comments: [2004-06-30 11:11:11] christian dot gottschalch at is-energy dot de BT again: bash-2.03# gdb /opt/netscape/server4/bin/https/bin/ns-httpd core.ns-httpd.1876.65.60001.60001.1088585722 GNU gdb 6.1 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "sparc-sun-solaris2.8"...(no debugging symbols found)... Core was generated by `ns-httpd -d /opt/netscape/server4/https-home/config'. Program terminated with signal 11, Segmentation fault. Reading symbols from /opt/netscape/server4/bin/https/libcccccc. cccccccccccccccccc... Loaded symbols for /opt/netscape/server4/bin/https/lib/libvdk200.so #0 0xfd603010 in nnfgrne () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 (gdb) bt #0 0xfd603010 in nnfgrne () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #1 0xfd78d2b4 in nlifigbl () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #2 0xfd601644 in nnfgiinit () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #3 0xfd6012bc in nnfgiinit () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #4 0xfd5fe0ac in nigconcbs () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #5 0xfd5d5754 in kwfnbcs () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #6 0xfd597c60 in kwfcmc () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #7 0xfd51bdb8 in kpudtch () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #8 0xfd5797bc in OCILobRead () from /opt/oracle/8.1.7/lib/libclntsh.so.8.0 #9 0xfde689d8 in _oci_open_server (dbname=0x1 , persistent=-33580208) at /opt/php4-STABLE-200406300630/ext/oci8/oci8.c:2531 #10 0xfde68f94 in oci_do_connect (ht=3, return_value=0x1eed7d8, this_ptr=0x0, return_value_used=1, tsrm_ls=0xe4dd28, persistent=0, exclusive=0) at /opt/php4-STABLE-200406300630/ext/oci8/oci8.c:2701 #11 0xfde6d5b0 in zif_ocilogon (ht=3, return_value=0x1eed7d8, this_ptr=0x0, return_value_used=1, tsrm_ls=0xe4dd28) at /opt/php4-STABLE-200406300630/ext/oci8/oci8.c:4340 #12 0xfdf64ff8 in execute (op_array=0x1ce58a8, tsrm_ls=0xe4dd28) at /opt/php4-STABLE-200406300630/Zend/zend_execute.c:1635 #13 0xfdf64d04 in execute (op_array=0xd175c0, tsrm_ls=0xe4dd28) at /opt/php4-STABLE-200406300630/Zend/zend_execute.c:1679 #14 0xfdf64d04 in execute (op_array=0x1ed4eb8, tsrm_ls=0xe4dd28) at /opt/php4-STABLE-200406300630/Zend/zend_execute.c:1679 #15 0xfdf64d04 in execute (op_array=0x1e86d30, tsrm_ls=0xe4dd28) at /opt/php4-STABLE-200406300630/Zend/zend_execute.c:1679 #16 0xfdf53b44 in zend_execute_scripts (type=8, tsrm_ls=0xe4dd28, retval=0x0, file_count=3) at /opt/php4-STABLE-200406300630/Zend/zend.c:891 #17 0xfdf19ba0 in php_execute_script (primary_file=0xfdb41548, tsrm_ls=0xe4dd28) at /opt/php4-STABLE-200406300630/main/main.c:1731 #18 0xfdf6bd08 in php4_execute (pb=0x1147a0, sn=0x8fd9fc, rq=0x8fda34) at /opt/php4-STABLE-200406300630/sapi/nsapi/nsapi.c:945 #19 0xff256dac in __0Fafunc_native_pool_wait_workPFP6GpblockP6HSessionP6HRequest_iUiP6GpblockP6HSessionP6HRequest () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #20 0xff2563cc in __0FNfunc_exec_strP6KFuncStructP6GpblockP6HSessionP6HRequest () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #21 0xff257364 in INTobject_execute () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #22 0xff25bfd8 in __0FQ_perform_serviceP6HSessionP6HRequestP6Mhttpd_object () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #23 0xff25c094 in INTservact_service () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #24 0xff25c3ac in INTservact_handle_processed () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #25 0xff28ac1c in __0fLHttpRequestUUnacceleratedRespondPCcPcTC () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #26 0xff2899f8 in __0fLHttpRequestNHandleRequestP6Gnetbuf () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #27 0xff28621c in __0fNDaemonSessionHRespondv () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #28 0xff2860a0 in __0fNDaemonSessionKThreadMainv () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #29 0xff285b24 in CThreadMain () from /opt/netscape/server4/bin/https/lib/libns-httpd40.so #30 0xfef42ad8 in _pt_root ()
#29013 [NEW]: Multiple logons cause handles to become invalid
From: cjbj at hotmail dot com
Operating system: Windows 2000
PHP version: 4.3.7
PHP Bug Type: OCI8 related
Bug description: Multiple logons cause handles to become invalid
Description:
Multiple logons within the same request cause handles to become invalid
and queries to fail.
Also see:
http://forums.oracle.com/forums/thread.jsp?forum=178&thread=251141
To reproduce, restart Apache and run the following file.
The same incorrect output occurs with ocilogon() inplace of ocinlogon().
Reproduce code:
---
===>BEGIN";
$rSth = OCIParse($c, $s);
$rRet = OCIExecute($rSth);
echo "";
while ($succ = OCIFetchInto($rSth, $row)) {
foreach ($row as $item) {
echo ($item?htmlentities($item):' ')." ";
}
echo "\n";
}
echo "===>CLOSE";
ocifreestatement($rSth);
}
$statement1 = "select dname from dept";
$statement2 = "select user from dual;";
echo "===>OCINLogin #1";
$c1 = OCINlogon('scott', 'tiger', 'MYDB' );
echo "===>Query first connection";
qry($c1, $statement1);
echo "===>OCINLogin #2";
$c2 = OCINlogon('hr', 'hr', 'MYDB');
echo "===>Re-query first connection";
qry($c1, $statement1);
echo "===>Re-query first connection";
qry($c1, $statement2);
?>
Expected result:
Three queries are successfully completed.
Actual result:
--
===>OCINLogin #1
OCIDebug: _oci_open_server new conn=0 dname=MYDB
OCIDebug: _oci_open_session new sess=3 user=scott
OCIDebug: oci_do_connect: id=4
===>Query first connection
===>BEGIN
OCIDebug: oci_parse "select dname from dept" id=5 conn=4
ACCOUNTING
RESEARCH
SALES
OPERATIONS
===>CLOSE
OCIDebug: START _oci_stmt_list_dtor: id=5 last_query="select dname from
dept"
OCIDebug: START _oci_column_hash_dtor: DNAME
OCIDebug: END _oci_column_hash_dtor: DNAME
OCIDebug: END _oci_stmt_list_dtor: id=5
===>OCINLogin #2
OCIDebug: _oci_open_session new sess=6 user=hr
OCIDebug: oci_do_connect: id=7
===>Re-query first connection
===>BEGIN
OCIDebug: oci_parse "select dname from dept" id=8 conn=4
Warning: ociexecute(): OCIStmtExecute: ORA-00942: table or view does not
exist in c:\cj\php\cj\contest.php on line 13
Warning: ocifetchinto(): OCIFetchInto: ORA-24374: define not done before
fetch or execute and fetch in c:\cj\php\cj\contest.php on line 15
===>CLOSE
OCIDebug: START _oci_stmt_list_dtor: id=8 last_query="select dname from
dept"
OCIDebug: END _oci_stmt_list_dtor: id=8
===>Re-query first connection
===>BEGIN
OCIDebug: oci_parse "select user from dual;" id=9 conn=4
Warning: ociexecute(): OCIStmtExecute: ORA-00911: invalid character in
c:\cj\php\cj\contest.php on line 13
Warning: ocifetchinto(): OCIFetchInto: ORA-24374: define not done before
fetch or execute and fetch in c:\cj\php\cj\contest.php on line 15
===>CLOSE
OCIDebug: START _oci_stmt_list_dtor: id=9 last_query="select user from
dual;"
OCIDebug: END _oci_stmt_list_dtor: id=9
OCIDebug: START php_rshutdown_oci
OCIDebug: END php_rshutdown_oci
OCIDebug: START _oci_conn_list_dtor: id=4
OCIDebug: nothing to do..
OCIDebug: START _oci_close_session: logging-off sess=3
OCIDebug: END _oci_conn_list_dtor: id=4
OCIDebug: START _oci_conn_list_dtor: id=7
OCIDebug: nothing to do..
OCIDebug: START _oci_close_session: logging-off sess=6
OCIDebug: END _oci_conn_list_dtor: id=7
OCIDebug: START _oci_close_server: detaching conn=2 dbname=MYDB
--
Edit bug report at http://bugs.php.net/?id=29013&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29013&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29013&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29013&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29013&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29013&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29013&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29013&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29013&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29013&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29013&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29013&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29013&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29013&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29013&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29013&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29013&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29013&r=float
#29011 [Opn]: ocilogon/oci_connect documentation misses charset parameter
ID: 29011 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com Status: Open Bug Type: OCI8 related Operating System: n/a -PHP Version: 4.3.7 +PHP Version: 5.0 New Comment: . Previous Comments: [2004-07-05 06:57:38] cjbj at hotmail dot com Description: The documentation for ocilogon and oci_connect mentions only three parameters. Looking at oci_do_connect() in the source for oci8.c (php5-200402232230) I can see there is a fourth parameter, the charset identifier. -- Edit this bug report at http://bugs.php.net/?id=29011&edit=1
#29012 [NEW]: Potential race during first connection
From: cjbj at hotmail dot com
Operating system: n/a
PHP version: 5.0.0RC3
PHP Bug Type: OCI8 related
Bug description: Potential race during first connection
Description:
The mutex locking in _oci_open_session() in
php-5.0.0RC3/ext/oci8/oci.c at about line 2676 may allow a
possible race. This was discovered from code inspection so I could be
wrong.
The current code is:
if (zend_ts_hash_find(persistent_sessions, hashed_details.c,
hashed_details.len+1, (void **) &session_list) != SUCCESS) {
zend_llist tmp;
/* first session, set up a session list */
zend_llist_init(&tmp, sizeof(oci_session), (llist_dtor_func_t)
_session_pcleanup, 1);
zend_ts_hash_update(persistent_sessions, hashed_details.c,
hashed_details.len+1, &tmp, sizeof(zend_llist), (void **) &session_list);
} else {
mutex_lock(mx_lock);
/* session list found, search for an idle session or an already
opened session by the current thread */
session = zend_llist_get_first(session_list);
while ((session != NULL) && session->thread && (session->thread !=
thread_id())) {
session = zend_llist_get_next(session_list);
}
if (session != NULL) {
/* mark session as busy */
session->thread = thread_id();
}
mutex_unlock(mx_lock);
}
I don't understand why there is no locking around the
zend_llist_init() or even zend_ts_hash_find() calls. If multiple
users log in at once then does zend_ts_hash_find() guarentee to return
SUCCESS for only one thread? If not, a suggested change is:
mutex_lock(mx_lock);
if (zend_ts_hash_find(persistent_sessions, hashed_details.c,
hashed_details.len+1, (void **) &session_list) != SUCCESS) {
zend_llist tmp;
/* first session, set up a session list */
zend_llist_init(&tmp, sizeof(oci_session), (llist_dtor_func_t)
_session_pcleanup, 1);
zend_ts_hash_update(persistent_sessions, hashed_details.c,
hashed_details.len+1, &tmp, sizeof(zend_llist), (void **) &session_list);
} else {
/* session list found, search for an idle session or an already
opened session by the current thread */
session = zend_llist_get_first(session_list);
while ((session != NULL) && session->thread && (session->thread !=
thread_id())) {
session = zend_llist_get_next(session_list);
}
if (session != NULL) {
/* mark session as busy */
session->thread = thread_id();
}
}
mutex_unlock(mx_lock);
--
Edit bug report at http://bugs.php.net/?id=29012&edit=1
--
Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29012&r=trysnapshot4
Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29012&r=trysnapshot5
Fixed in CVS: http://bugs.php.net/fix.php?id=29012&r=fixedcvs
Fixed in release: http://bugs.php.net/fix.php?id=29012&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=29012&r=needtrace
Need Reproduce Script: http://bugs.php.net/fix.php?id=29012&r=needscript
Try newer version: http://bugs.php.net/fix.php?id=29012&r=oldversion
Not developer issue:http://bugs.php.net/fix.php?id=29012&r=support
Expected behavior: http://bugs.php.net/fix.php?id=29012&r=notwrong
Not enough info:http://bugs.php.net/fix.php?id=29012&r=notenoughinfo
Submitted twice:http://bugs.php.net/fix.php?id=29012&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=29012&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29012&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=29012&r=dst
IIS Stability: http://bugs.php.net/fix.php?id=29012&r=isapi
Install GNU Sed:http://bugs.php.net/fix.php?id=29012&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=29012&r=float
#29011 [NEW]: ocilogon/oci_connect documentation misses charset parameter
From: cjbj at hotmail dot com Operating system: n/a PHP version: 4.3.7 PHP Bug Type: OCI8 related Bug description: ocilogon/oci_connect documentation misses charset parameter Description: The documentation for ocilogon and oci_connect mentions only three parameters. Looking at oci_do_connect() in the source for oci8.c (php5-200402232230) I can see there is a fourth parameter, the charset identifier. -- Edit bug report at http://bugs.php.net/?id=29011&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=29011&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=29011&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=29011&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=29011&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=29011&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=29011&r=needscript Try newer version: http://bugs.php.net/fix.php?id=29011&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=29011&r=support Expected behavior: http://bugs.php.net/fix.php?id=29011&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=29011&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=29011&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=29011&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=29011&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=29011&r=dst IIS Stability: http://bugs.php.net/fix.php?id=29011&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=29011&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=29011&r=float
#22692 [Com]: Oracle 9i
ID: 22692 Comment by: cjbj at hotmail dot com Reported By: frusti at frusti dot com Status: Open Bug Type: Feature/Change Request Operating System: Windows 2000 Server SP3 PHP Version: 4.3.2RC1 New Comment: Php_oci8 is the "newest" PHP Oracle extension. It uses Oracle's most current C API - called OCI8 because it was introduced with Oracle version 8. Previous Comments: [2003-03-14 03:18:59] frusti at frusti dot com Hello, I am using portable SQL with ADODB and now I have performance-problemes with Oracle 9i. I have also tested it with PEAR-DB, the same problem. With Oracle 8i it goes well. Have anyone an idea when a newer Oracle-extensions come out? At moment I use php_oci8. Please give me a feedback as soon as possible. Thanks and best regards, Frast Andreas -- Edit this bug report at http://bugs.php.net/?id=22692&edit=1
#19714 [Com]: OCI8: Using default user in OCI8 functions
ID: 19714
Comment by: cjbj at hotmail dot com
Reported By: jomar at hafro dot is
Status: Assigned
Bug Type: Feature/Change Request
Operating System: SunOS
PHP Version: 4.2.2
Assigned To: maxim
New Comment:
From
http://otn.oracle.com/tech/opensource/php/php_troubleshooting_faq.html#extauth
"Allowing externally authenticated database connections over the web
would be a potential security risk for most configurations. Luckily
PHP's OCI8 extension will not allow external authentication where the
username is "/" and the password an empty string. The call in PHP's
oci8.c to Oracle's OCISessionBegin() always sets the credential flag to
OCI_CRED_RDBMS. To support operating system authentication the PHP
source code would have to be changed to pass Oracle the OCI_CRED_EXT
flag when appropriate."
Previous Comments:
[2002-11-11 13:08:10] [EMAIL PROTECTED]
Oracle does not seem to read user/pass if it is passed to it as the
username via OCILogon.
When second parameter is an empty strng OCISessionBegin() complains
about the "NULL password Given" while if username contains '/' it is 1)
unparsed by API, 2) will still leave OCISessionBegin() without a
password.
I will take a look at it.
[2002-10-02 08:04:17] jomar at hafro dot is
I´m using Apache enviroment :
SetEnv ORACLE_HOME /usr/oracle
SetEnv ORA_NLS33 /usr/oracle/ocommon/nls/admin/data
SetEnv NLS_LANG icelandic_america
I also set the tns_names and more env within root enviroment before I
execute apachectl start running php as a module.
I also compiled Php with Oci8.
I´m having trouble with ocilogon function when I use the
ocilogon("/","") (default user/nopass,server)
If I logon using a valid username and password then it is ok, but when
I use this method it returns an ora error :
ORA-01005: null password given; logon denied
I also have the ora libs and if I use ora_logon("/","") that seems to
work.
--
Edit this bug report at http://bugs.php.net/?id=19714&edit=1
#27303 [Fbk->Opn]: OCIBindByName binds numeric PHP values as characters
ID: 27303 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: * PHP Version: 4CVS-2004-02-18 (stable) New Comment: It would seem logical and faster to bind PHP integers as Oracle integers. It might make the "returning into" example from before simpler (no need to specify a width) and hence more intuitive and foolproof. A new constant OCI_B_INT could map to SQLT_INT (depending on how PHP internally stores integers). Previous Comments: [2004-02-20 02:38:04] [EMAIL PROTECTED] Yep, currently oci_bind_by_name uses SQLT_CHR for all types, except LOBs, FILEs & ROWIDs. You propose to add new constant - OCI_B_INT (SQLT_INT) to use it with numeric values? Am I right? [2004-02-18 02:14:18] cjbj at hotmail dot com Description: Numeric PHP variables seem to be treated as strings when bound with OCIBindByName. The means the desired number of significant digits needs to be specified in the OCIBindByName call. Othewise only the most significant digit is returned. PHP scripts could be simpler and safer to write if: (i) a pre-existing numeric PHP variable automatically caused a SQLT_INT bind (ii) OCI's SQLT_INT type could be specified in the OCIBindByName call, with a new OCI_B_xxx define For example, try a RETURNING INTO clause with a sequence value: \n"; } OCICommit($conn); ?> The output is: Bind variable is 1 Bind variable is 2 Bind variable is 3 Bind variable is 4 Bind variable is 5 Bind variable is 6 Bind variable is 7 Bind variable is 8 Bind variable is 9 Bind variable is 1 ... [This continues with 10 rows of 1's, then 10 rows of 2's etc. as if the least significant digit(s) are being stripped.] Querying the table in a SQL*Plus sessions shows the inserts are occuring correctly and the sequence number is increasing past nine: MYDATA SEQCOL -- Some data 1 Some data 2 Some data 3 Some data 4 Some data 5 Some data 6 Some data 7 Some data 8 Some data 9 Some data10 ... Some data 199 Expected result Bind variable is 1 Bind variable is 2 Bind variable is 3 Bind variable is 4 Bind variable is 5 Bind variable is 6 Bind variable is 7 Bind variable is 8 Bind variable is 9 Bind variable is 10 ... Bind variable is 199 Testcase 2 is to set $mybv to a value before the OCIBindByName by uncommenting the line marked 2nd test. The value set is bound as a string. The number of digits in it will determine the maximum width of the returned bind result. For example if $mybv is set to 11, then all two-digit values are displayed correctly. Testcase 3 is to pass a width to OCIBindByName. Uncomment the text marked 3rd test. This works until the number of digits in the sequence number is greater than the passed width. Another different testcase might be calling a PL/SQL procedure with a IN/OUT parameter. Although the passed value is correct, the out value may not be. If the current behavior is deemed desired, can this bug be made a documentation bug? Users may be easily tricked because there is no mention of the default bind type being character, and the OCIBindByName documentation "and the necessary storage space will be allocated" could be thought to apply to PHP numeric variables. -- Edit this bug report at http://bugs.php.net/?id=27303&edit=1
#27485 [Com]: OCI clob column objects inconsistent in result set
ID: 27485
Comment by: cjbj at hotmail dot com
Reported By: jseverson at myersinternet dot com
Status: Open
Bug Type: OCI8 related
Operating System: Redhat Linux kernel 2.4.18-3
PHP Version: 4.3.4
New Comment:
What does using
OCIFetchInto($stmt, $table_a_row, OCI_ASSOC+OCI_RETURN_NULLS);
give?
Previous Comments:
[2004-03-03 16:58:44] jseverson at myersinternet dot com
Description:
When handling clob columns in Oracle, PHP is inconsistent in the way
that it returns the result set of your query containing that clob
column when the clob is null. In one case, the result set contains an
Object, and in another case, the result set doesn't contain any Object,
even though in both cases, the VALUE of the object after load() is
"empty" (column is null).
We believe what causes these two different cases is that in the case of
an Object being returned, the table being queried had multiple (3) clob
columns. The other case when no Object was returned, the table being
queried had only one (1) clob column.
This makes it nearly impossible to handle your result set data since
you can't call the load() function if the object doesn't exist without
getting an error, but on the other hand, you can't check whether or not
the clob is empty because an Object is present even when the Object has
no value.
It seems like the correct behavior would be to always return an Object,
so that you don't have to first check whether or not the Object is
empty or not, before called the load() OCI function.
Reproduce code:
---
//table_a has one clob and clob is null
$sql = "select * from test_schema.table_a where primary_key=1";
$stmt = OCIParse($conn_ora, $sql);
OCIExecute($stmt, OCI_DEFAULT);
OCIFetchInto($stmt, $table_a_row, OCI_ASSOC);
OCIFreeStatement($stmt);
echo "";
var_dump($table_a_row);
//table_b has multiple clobs (3) and all clobs are null
$sql = "select * from test_schema.table_b where primary_key=1";
$stmt = OCIParse($conn_ora, $sql);
OCIExecute($stmt, OCI_DEFAULT);
OCIFetchInto($stmt, $table_b_row, OCI_ASSOC);
OCIFreeStatement($stmt);
echo "";
var_dump($table_b_row);
Expected result:
array(1) {
["CLOB_1"]=>
object(OCI-Lob)(1) {
["descriptor"]=>
resource(9) of type (oci8 descriptor)
}
}
array(3) {
["CLOB_1"]=>
object(OCI-Lob)(1) {
["descriptor"]=>
resource(10) of type (oci8 descriptor)
}
["CLOB_2"]=>
object(OCI-Lob)(1) {
["descriptor"]=>
resource(11) of type (oci8 descriptor)
}
["CLOB_3"]=>
object(OCI-Lob)(1) {
["descriptor"]=>
resource(12) of type (oci8 descriptor)
}
}
-- OR -
array(0) {
}
array(0) {
}
Actual result:
--
array(0) {
}
array(3) {
["CLOB_1"]=>
object(OCI-Lob)(1) {
["descriptor"]=>
resource(9) of type (oci8 descriptor)
}
["CLOB_2"]=>
object(OCI-Lob)(1) {
["descriptor"]=>
resource(10) of type (oci8 descriptor)
}
["CLOB_3"]=>
object(OCI-Lob)(1) {
["descriptor"]=>
resource(11) of type (oci8 descriptor)
}
}
--
Edit this bug report at http://bugs.php.net/?id=27485&edit=1
#27355 [Com]: rand() generates even-odd-even-odd numbers
ID: 27355 Comment by: cjbj at hotmail dot com Reported By: chrisrogers at planetunreal dot com Status: Open Bug Type: Math related Operating System: Windows PHP Version: 4.3.4 New Comment: May be related to bug 27052 which I reproduced (with the same pattern too). Previous Comments: [2004-02-22 15:25:20] chrisrogers at planetunreal dot com Description: The rand() function under Windows XP Pro and possibly other Windows OSs generates numbers in a strict even-odd-even-odd pattern. The pattern doesn't occur on *nix OSs Reproduce code: --- \n"; ?> Expected result: expected numbers with no noticable pattern Actual result: -- numbers were in an even-odd-even-odd pattern -- Edit this bug report at http://bugs.php.net/?id=27355&edit=1
#27303 [NEW]: OCIBindByName binds numeric PHP values as characters
From: cjbj at hotmail dot com Operating system: PHP version: 4CVS-2004-02-18 (stable) PHP Bug Type: OCI8 related Bug description: OCIBindByName binds numeric PHP values as characters Description: Numeric PHP variables seem to be treated as strings when bound with OCIBindByName. The means the desired number of significant digits needs to be specified in the OCIBindByName call. Othewise only the most significant digit is returned. PHP scripts could be simpler and safer to write if: (i) a pre-existing numeric PHP variable automatically caused a SQLT_INT bind (ii) OCI's SQLT_INT type could be specified in the OCIBindByName call, with a new OCI_B_xxx define For example, try a RETURNING INTO clause with a sequence value: \n"; } OCICommit($conn); ?> The output is: Bind variable is 1 Bind variable is 2 Bind variable is 3 Bind variable is 4 Bind variable is 5 Bind variable is 6 Bind variable is 7 Bind variable is 8 Bind variable is 9 Bind variable is 1 ... [This continues with 10 rows of 1's, then 10 rows of 2's etc. as if the least significant digit(s) are being stripped.] Querying the table in a SQL*Plus sessions shows the inserts are occuring correctly and the sequence number is increasing past nine: MYDATA SEQCOL -- Some data 1 Some data 2 Some data 3 Some data 4 Some data 5 Some data 6 Some data 7 Some data 8 Some data 9 Some data10 ... Some data 199 Expected result Bind variable is 1 Bind variable is 2 Bind variable is 3 Bind variable is 4 Bind variable is 5 Bind variable is 6 Bind variable is 7 Bind variable is 8 Bind variable is 9 Bind variable is 10 ... Bind variable is 199 Testcase 2 is to set $mybv to a value before the OCIBindByName by uncommenting the line marked 2nd test. The value set is bound as a string. The number of digits in it will determine the maximum width of the returned bind result. For example if $mybv is set to 11, then all two-digit values are displayed correctly. Testcase 3 is to pass a width to OCIBindByName. Uncomment the text marked 3rd test. This works until the number of digits in the sequence number is greater than the passed width. Another different testcase might be calling a PL/SQL procedure with a IN/OUT parameter. Although the passed value is correct, the out value may not be. If the current behavior is deemed desired, can this bug be made a documentation bug? Users may be easily tricked because there is no mention of the default bind type being character, and the OCIBindByName documentation "and the necessary storage space will be allocated" could be thought to apply to PHP numeric variables. -- Edit bug report at http://bugs.php.net/?id=27303&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27303&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27303&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27303&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27303&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27303&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27303&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27303&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27303&r=support Expected behavior: http://bugs.php.net/fix.php?id=27303&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27303&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27303&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27303&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27303&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27303&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27303&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27303&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27303&r=float
#27203 [Com]: Querying database columns with name HIDE fails to get data
ID: 27203 Comment by: cjbj at hotmail dot com Reported By: jakob at grimstveit dot no Status: Feedback Bug Type: OCI8 related Operating System: RedHat 9.0 PHP Version: 4.3.4 New Comment: With respect to the filer, (i) this bug contains no reproducible PHP code (ii) no table descriptions (iii) no sample data. However from looking at the very little information available, the data at http://www.starshipping.com/~jakobbg/datafound.txt shows both a HIDE column and a TYGGEGUMMI column. The HIDE column in datalacking.txt has the same data as the datafound.txt HIDE column. The datalacking.txt results are probably due to selecting two columns called HIDE from two tables e.g. as t1.hide and t2.hide. When doing this and using associative arrays, only one column is returned by PHP. There are a couple of recent user comments in http://www.php.net/manual/en/function.ocifetchinto.php talking about this. The solution I added there recently is to use column aliases. Given how PHP associative arrays do not include a table name qualifier, I'd say this isn't a bug. Previous Comments: [2004-02-10 17:54:22] [EMAIL PROTECTED] Nobody is asking you to _install_ the snapshot, you can just as easily run the script with CLI..do NOT touch this report before you're giving the asked feedback. [2004-02-10 09:24:02] jakob at grimstveit dot no Will do this as soon as possible. Creating a SuSE9 vmware installation and will compile apache and php with same options as on the rhl9-box used here. Can't deploy into same place since this is a prod-server :-) [2004-02-10 08:04:23] [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 [2004-02-10 05:09:58] jakob at grimstveit dot no About "Reproduce code": Actual SQL is shown in URL's described in "Actual result" area. Sorry about that. [2004-02-10 05:06:52] jakob at grimstveit dot no Description: When running this query it gives 10 NULL values out of 12 rows, while in SQLplus&Tora it gives me the value actually found in the database for all rows. When renaming column to something random in the query, the data gets through to PHP, thus I guess it's related to the HIDE column being a keyword of some kind. Reproduce code: --- $query = "select hide from something" Expected result: A complete resultset Actual result: -- A resultset lacking values in the column named HIDE in 10 out of 12 rows. See http://www.starshipping.com/~jakobbg/datafound.txt (correct resultset with sql row renamed to tyggegummi and http://www.starshipping.com/~jakobbg/datalacking.txt with original buggy resultset. Data ($result) printed with print_r() Hope this will be fixed soon. -- Edit this bug report at http://bugs.php.net/?id=27203&edit=1
#27117 [Opn]: Configuration patch to compile oci8 extension with Oracle 10g
ID: 27117 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com Status: Open Bug Type: OCI8 related Operating System: RH Linux AS 3 PHP Version: 4CVS-2004-02-02 (stable) New Comment: H. Pasted from wrong buffer (or right buffer on wrong machine). The replacement patch should have the line OCI8_VERSION=10.1, not OCI8_VERSION=9.0 Previous Comments: [2004-02-02 03:37:27] cjbj at hotmail dot com I've grokked the m4 9.0/9.2 hack and see it isn't needed for 10.1. The revised suggested patch is: *** config.m4.orig 2003-10-03 16:07:05.0 +1000 --- config.m4 2004-02-02 19:22:57.0 +1100 *** *** 23,28 --- 23,30 if test -s "$OCI8_DIR/orainst/unix.rgs"; then OCI8_VERSION=`grep '"ocommon"' $OCI8_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$OCI8_VERSION" && OCI8_VERSION=7.3 + elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then + OCI8_VERSION=9.0 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.8.0; then *** *** 115,120 --- 117,129 ]) ;; + 10.1) + PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) + PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) + AC_DEFINE(HAVE_OCI_9_2,1,[ ]) + ;; + *) AC_MSG_ERROR(Unsupported Oracle version!) ;; ---------------- [2004-02-02 00:36:00] cjbj at hotmail dot com Description: This patch to ext/oci8/config.m4 allows compilation with Oracle 10g: --- config.m4.orig 2003-10-03 16:07:05.0 +1000 +++ config.m4 2004-02-02 16:09:26.0 +1100 @@ -23,6 +23,8 @@ if test -s "$OCI8_DIR/orainst/unix.rgs"; then OCI8_VERSION=`grep '"ocommon"' $OCI8_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$OCI8_VERSION" && OCI8_VERSION=7.3 + elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then +OCI8_VERSION=10.1 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.8.0; then @@ -115,6 +117,26 @@ ]) ;; +10.1) + PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) + PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) + + dnl These functions are only available in version >= 9.2 + PHP_CHECK_LIBRARY(clntsh, OCIEnvNlsCreate, + [ +PHP_CHECK_LIBRARY(clntsh, OCINlsCharSetNameToId, +[ + AC_DEFINE(HAVE_OCI_9_2,1,[ ]) + OCI8_VERSION=10.1 +], [], [ + -L$OCI8_DIR/lib $OCI8_SHARED_LIBADD +]) + ], [], [ +-L$OCI8_DIR/lib $OCI8_SHARED_LIBADD + ]) + ;; + *) AC_MSG_ERROR(Unsupported Oracle version!) ;; If readers need to manually apply this patch, run ./buildconf before running ./configure and make. See also http://bugs.php.net/27093 To install Oracle's OCI header and library files from the Oracle 10g Client CD, run the installer and choose the "Administrator" option. -- Edit this bug report at http://bugs.php.net/?id=27117&edit=1
#27117 [Opn]: Configuration patch to compile oci8 extension with Oracle 10g
ID: 27117 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com Status: Open Bug Type: OCI8 related Operating System: RH Linux AS 3 PHP Version: 4CVS-2004-02-02 (stable) New Comment: I've grokked the m4 9.0/9.2 hack and see it isn't needed for 10.1. The revised suggested patch is: *** config.m4.orig 2003-10-03 16:07:05.0 +1000 --- config.m4 2004-02-02 19:22:57.0 +1100 *** *** 23,28 --- 23,30 if test -s "$OCI8_DIR/orainst/unix.rgs"; then OCI8_VERSION=`grep '"ocommon"' $OCI8_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$OCI8_VERSION" && OCI8_VERSION=7.3 + elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then + OCI8_VERSION=9.0 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.8.0; then *** *** 115,120 --- 117,129 ]) ;; + 10.1) + PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) + PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) + AC_DEFINE(HAVE_OCI_9_2,1,[ ]) + ;; + *) AC_MSG_ERROR(Unsupported Oracle version!) ;; Previous Comments: ---------------- [2004-02-02 00:36:00] cjbj at hotmail dot com Description: This patch to ext/oci8/config.m4 allows compilation with Oracle 10g: --- config.m4.orig 2003-10-03 16:07:05.0 +1000 +++ config.m4 2004-02-02 16:09:26.0 +1100 @@ -23,6 +23,8 @@ if test -s "$OCI8_DIR/orainst/unix.rgs"; then OCI8_VERSION=`grep '"ocommon"' $OCI8_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$OCI8_VERSION" && OCI8_VERSION=7.3 + elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then +OCI8_VERSION=10.1 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.8.0; then @@ -115,6 +117,26 @@ ]) ;; +10.1) + PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) + PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) + + dnl These functions are only available in version >= 9.2 + PHP_CHECK_LIBRARY(clntsh, OCIEnvNlsCreate, + [ +PHP_CHECK_LIBRARY(clntsh, OCINlsCharSetNameToId, +[ + AC_DEFINE(HAVE_OCI_9_2,1,[ ]) + OCI8_VERSION=10.1 +], [], [ + -L$OCI8_DIR/lib $OCI8_SHARED_LIBADD +]) + ], [], [ +-L$OCI8_DIR/lib $OCI8_SHARED_LIBADD + ]) + ;; + *) AC_MSG_ERROR(Unsupported Oracle version!) ;; If readers need to manually apply this patch, run ./buildconf before running ./configure and make. See also http://bugs.php.net/27093 To install Oracle's OCI header and library files from the Oracle 10g Client CD, run the installer and choose the "Administrator" option. -- Edit this bug report at http://bugs.php.net/?id=27117&edit=1
#27093 [Opn]: Incorrect casts in oci8.c prevent compiling with Oracle 10g
ID: 27093
User updated by: cjbj at hotmail dot com
Reported By: cjbj at hotmail dot com
Status: Open
Bug Type: Compile Failure
Operating System: RH Linux 3
PHP Version: 4CVS-2004-01-30 (stable)
New Comment:
To compile with Oracle 10g also see http://bugs.php.net/27117
Previous Comments:
[2004-02-01 19:22:43] cjbj at hotmail dot com
Diff -cw gives:
*** oci8.c.orig 2004-01-27 01:08:29.0 +1100
--- oci8.c 2004-02-02 11:24:46.0 +1100
***
*** 4833,4839
CALL_OCI_RETURN(connection->error, OCICollAppend(
connection->session->pEnv,
connection->pError,
! (dword *)0,
&null_ind,
coll->coll));
if (connection->error) {
--- 4833,4839
CALL_OCI_RETURN(connection->error, OCICollAppend(
connection->session->pEnv,
connection->pError,
! (dvoid *)0,
&null_ind,
coll->coll));
if (connection->error) {
***
*** 5139,5145
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)0,
&null_ind,
coll->coll));
if (connection->error) {
--- 5139,5145
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)0,
&null_ind,
coll->coll));
if (connection->error) {
***
*** 5172,5178
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)&dt,
&new_ind,
coll->coll));
--- 5172,5178
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)&dt,
&new_ind,
coll->coll));
***
*** 5200,5206
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)ocistr,
&new_ind,
coll->coll));
--- 5200,5206
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)ocistr,
&new_ind,
coll->coll));
***
*** 5239,5245
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)&num,
&new_ind,
coll->coll));
--- 5239,5245
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)&num,
&new_ind,
coll->coll));
[2004-01-30 02:04:49] cjbj at hotmail dot com
Description:
The casts to "(dword *)" in OCICollAppend() and OCICollAssignElem()
calls in oci8.c should be changed to "(dvoid *)" to match the
prototypes.
Without this correction the file will fail to compile in Oracle 10g:
the very obsolete dword no longer appears to be defined in oratypes.h.
Actual result:
--
Without this fix, compiling php4-STABLE-200401300430 with --en
#27117 [NEW]: Configuration patch to compile oci8 extension with Oracle 10g
From: cjbj at hotmail dot com Operating system: RH Linux AS 3 PHP version: 4CVS-2004-02-02 (stable) PHP Bug Type: *Configuration Issues Bug description: Configuration patch to compile oci8 extension with Oracle 10g Description: This patch to ext/oci8/config.m4 allows compilation with Oracle 10g: --- config.m4.orig 2003-10-03 16:07:05.0 +1000 +++ config.m4 2004-02-02 16:09:26.0 +1100 @@ -23,6 +23,8 @@ if test -s "$OCI8_DIR/orainst/unix.rgs"; then OCI8_VERSION=`grep '"ocommon"' $OCI8_DIR/orainst/unix.rgs | sed 's/[ ][ ]*/:/g' | cut -d: -f 6 | cut -c 2-4` test -z "$OCI8_VERSION" && OCI8_VERSION=7.3 + elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.10.1; then +OCI8_VERSION=10.1 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.9.0; then OCI8_VERSION=9.0 elif test -f $OCI8_DIR/lib/libclntsh.$SHLIB_SUFFIX_NAME.8.0; then @@ -115,6 +117,26 @@ ]) ;; +10.1) + PHP_ADD_LIBRARY(clntsh, 1, OCI8_SHARED_LIBADD) + PHP_ADD_LIBPATH($OCI8_DIR/lib, OCI8_SHARED_LIBADD) + AC_DEFINE(HAVE_OCI8_ATTR_STATEMENT,1,[ ]) + + dnl These functions are only available in version >= 9.2 + PHP_CHECK_LIBRARY(clntsh, OCIEnvNlsCreate, + [ +PHP_CHECK_LIBRARY(clntsh, OCINlsCharSetNameToId, +[ + AC_DEFINE(HAVE_OCI_9_2,1,[ ]) + OCI8_VERSION=10.1 +], [], [ + -L$OCI8_DIR/lib $OCI8_SHARED_LIBADD +]) + ], [], [ +-L$OCI8_DIR/lib $OCI8_SHARED_LIBADD + ]) + ;; + *) AC_MSG_ERROR(Unsupported Oracle version!) ;; If readers need to manually apply this patch, run ./buildconf before running ./configure and make. See also http://bugs.php.net/27093 To install Oracle's OCI header and library files from the Oracle 10g Client CD, run the installer and choose the "Administrator" option. -- Edit bug report at http://bugs.php.net/?id=27117&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27117&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27117&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27117&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27117&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27117&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27117&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27117&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27117&r=support Expected behavior: http://bugs.php.net/fix.php?id=27117&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27117&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27117&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27117&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27117&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27117&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27117&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27117&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27117&r=float
#27093 [Opn]: Incorrect casts in oci8.c prevent compiling with Oracle 10g
ID: 27093
User updated by: cjbj at hotmail dot com
Reported By: cjbj at hotmail dot com
Status: Open
Bug Type: Compile Failure
Operating System: RH Linux 3
PHP Version: 4CVS-2004-01-30 (stable)
New Comment:
Diff -cw gives:
*** oci8.c.orig 2004-01-27 01:08:29.0 +1100
--- oci8.c 2004-02-02 11:24:46.0 +1100
***
*** 4833,4839
CALL_OCI_RETURN(connection->error, OCICollAppend(
connection->session->pEnv,
connection->pError,
! (dword *)0,
&null_ind,
coll->coll));
if (connection->error) {
--- 4833,4839
CALL_OCI_RETURN(connection->error, OCICollAppend(
connection->session->pEnv,
connection->pError,
! (dvoid *)0,
&null_ind,
coll->coll));
if (connection->error) {
***
*** 5139,5145
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)0,
&null_ind,
coll->coll));
if (connection->error) {
--- 5139,5145
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)0,
&null_ind,
coll->coll));
if (connection->error) {
***
*** 5172,5178
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)&dt,
&new_ind,
coll->coll));
--- 5172,5178
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)&dt,
&new_ind,
coll->coll));
***
*** 5200,5206
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)ocistr,
&new_ind,
coll->coll));
--- 5200,5206
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)ocistr,
&new_ind,
coll->coll));
***
*** 5239,5245
connection->session->pEnv,
connection->pError,
ndx,
! (dword *)&num,
&new_ind,
coll->coll));
--- 5239,5245
connection->session->pEnv,
connection->pError,
ndx,
! (dvoid *)&num,
&new_ind,
coll->coll));
Previous Comments:
[2004-01-30 02:04:49] cjbj at hotmail dot com
Description:
The casts to "(dword *)" in OCICollAppend() and OCICollAssignElem()
calls in oci8.c should be changed to "(dvoid *)" to match the
prototypes.
Without this correction the file will fail to compile in Oracle 10g:
the very obsolete dword no longer appears to be defined in oratypes.h.
Actual result:
--
Without this fix, compiling php4-STABLE-200401300430 with --enable-oci8
gives:
/home/cjbj/php/ext/oci8/oci8.c:4833: `dword' undeclared (first use in
this function)
--
Edit this bug report at http://bugs.php.net/?id=27093&edit=1
#27093 [NEW]: Incorrect casts in oci8.c prevent compiling with Oracle 10g
From: cjbj at hotmail dot com Operating system: RH Linux 3 PHP version: 4CVS-2004-01-30 (stable) PHP Bug Type: Compile Failure Bug description: Incorrect casts in oci8.c prevent compiling with Oracle 10g Description: The casts to "(dword *)" in OCICollAppend() and OCICollAssignElem() calls in oci8.c should be changed to "(dvoid *)" to match the prototypes. Without this correction the file will fail to compile in Oracle 10g: the very obsolete dword no longer appears to be defined in oratypes.h. Actual result: -- Without this fix, compiling php4-STABLE-200401300430 with --enable-oci8 gives: /home/cjbj/php/ext/oci8/oci8.c:4833: `dword' undeclared (first use in this function) -- Edit bug report at http://bugs.php.net/?id=27093&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=27093&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=27093&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=27093&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=27093&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=27093&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=27093&r=needscript Try newer version: http://bugs.php.net/fix.php?id=27093&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=27093&r=support Expected behavior: http://bugs.php.net/fix.php?id=27093&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=27093&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=27093&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=27093&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=27093&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=27093&r=dst IIS Stability: http://bugs.php.net/fix.php?id=27093&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=27093&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=27093&r=float
#26744 [Csd]: php_oci8.dll is missing from prebuilt Windows binaries
ID: 26744 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com Status: Closed Bug Type: OCI8 related Operating System: W2K -PHP Version: 5.0.0b2 (beta2) +PHP Version: 5.0.0b3 (beta3) New Comment: Confirmed resolved in http://snaps.php.net/win32/php5-win32-latest.zip as of now. Thanks. Previous Comments: [2004-01-02 10:28:10] [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. [2004-01-01 22:11:50] cjbj at hotmail dot com The Windows snapshot http://snaps.php.net/win32/php5-win32-latest.zip is still missing php_oci8.dll [2003-12-30 10:37:26] [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 Try it about 4 hours from now. [2003-12-30 00:09:02] cjbj at hotmail dot com Description: Php_oci8.dll is missing from the bundle: http://www.php.net/get/php-5.0.0b3-Win32.zip/from/a/mirror The old php_oracle.dll library exists. The oci8 extension source code exists in the source bundle: http://www.php.net/get/php-5.0.0b3.tar.gz/from/a/mirror There is nothing in the various php5 announcements, or in http://www.php.net/ChangeLog-5.php that mentions the extension. This problem was raised in the php-db mail list: http://news.php.net/article.php?group=php.db&article=32200 The last time I pulled PHP5 (on September 3, 2003) php_oci8.dll was in the pre-built bundle. -- Edit this bug report at http://bugs.php.net/?id=26744&edit=1
#26744 [Fbk->Opn]: php_oci8.dll is missing from prebuilt Windows binaries
ID: 26744 User updated by: cjbj at hotmail dot com Reported By: cjbj at hotmail dot com -Status: Feedback +Status: Open Bug Type: OCI8 related Operating System: W2K PHP Version: 5.0.0b2 (beta2) New Comment: The Windows snapshot http://snaps.php.net/win32/php5-win32-latest.zip is still missing php_oci8.dll Previous Comments: [2003-12-30 10:37:26] [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 Try it about 4 hours from now. [2003-12-30 00:09:02] cjbj at hotmail dot com Description: Php_oci8.dll is missing from the bundle: http://www.php.net/get/php-5.0.0b3-Win32.zip/from/a/mirror The old php_oracle.dll library exists. The oci8 extension source code exists in the source bundle: http://www.php.net/get/php-5.0.0b3.tar.gz/from/a/mirror There is nothing in the various php5 announcements, or in http://www.php.net/ChangeLog-5.php that mentions the extension. This problem was raised in the php-db mail list: http://news.php.net/article.php?group=php.db&article=32200 The last time I pulled PHP5 (on September 3, 2003) php_oci8.dll was in the pre-built bundle. -- Edit this bug report at http://bugs.php.net/?id=26744&edit=1
#26744 [NEW]: php_oci8.dll is missing from prebuilt Windows binaries
From: cjbj at hotmail dot com Operating system: W2K PHP version: 5.0.0b2 (beta2) PHP Bug Type: OCI8 related Bug description: php_oci8.dll is missing from prebuilt Windows binaries Description: Php_oci8.dll is missing from the bundle: http://www.php.net/get/php-5.0.0b3-Win32.zip/from/a/mirror The old php_oracle.dll library exists. The oci8 extension source code exists in the source bundle: http://www.php.net/get/php-5.0.0b3.tar.gz/from/a/mirror There is nothing in the various php5 announcements, or in http://www.php.net/ChangeLog-5.php that mentions the extension. This problem was raised in the php-db mail list: http://news.php.net/article.php?group=php.db&article=32200 The last time I pulled PHP5 (on September 3, 2003) php_oci8.dll was in the pre-built bundle. -- Edit bug report at http://bugs.php.net/?id=26744&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=26744&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=26744&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=26744&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=26744&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=26744&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=26744&r=needscript Try newer version: http://bugs.php.net/fix.php?id=26744&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=26744&r=support Expected behavior: http://bugs.php.net/fix.php?id=26744&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=26744&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=26744&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=26744&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=26744&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=26744&r=dst IIS Stability: http://bugs.php.net/fix.php?id=26744&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=26744&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=26744&r=float
#25945 [NEW]: APACHE_INCLUDE is pre-expanded in Makefile
From: cjbj at hotmail dot com Operating system: Linux (RH AS 2.1) PHP version: 4.3.3 PHP Bug Type: *Compile Issues Bug description: APACHE_INCLUDE is pre-expanded in Makefile Description: I'm having some problems with a recalcitrant apxs program. It returns a bogus path for the Apache headers. The Makefile therefore is wrong and sapi_apache.c fails to compile. The APACHE_INCLUDE variable in the Makefile is not used anywhere so changing it has no effect. My configure line is: --with-oci8=$ORACLE_HOME --with-apxs=$ORACLE_HOME/Apache/Apache/bin/apxs --enable-sigchild The resulting Makefile is: ... APACHE_INCLUDE = -I/include ... sapi/apache/sapi_apache.lo: /home/cjbj/php-4.3.3/sapi/apache/sapi_apache.c $(LIBTOOL) --mode=compile $(CC) ... -I/include ... ... The problem I'm reporting is the compile line. It has already expanded the Apache path, so any change to APACHE_INCLUDE is never used. It would make working around this and similar problems easier if the compile line was: $(LIBTOOL) --mode=compile $(CC) ... -I$(APACHE_INCLUDE) ... If this is not possible, then maybe the "APACHE_INCLUDE = -I/include" line could be removed altogether from the Makefile. -- Edit bug report at http://bugs.php.net/?id=25945&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=25945&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=25945&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=25945&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=25945&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=25945&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=25945&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=25945&r=support Expected behavior: http://bugs.php.net/fix.php?id=25945&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=25945&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=25945&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=25945&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=25945&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=25945&r=dst IIS Stability: http://bugs.php.net/fix.php?id=25945&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=25945&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=25945&r=float
#25818 [Com]: Valid select using OCI8 causes integer overflow error in Oracle
ID: 25818
Comment by: cjbj at hotmail dot com
Reported By: iolaire dot mckinnon at vcint dot com
Status: Open
Bug Type: OCI8 related
Operating System: RedHat Linux 9
PHP Version: 4.3.3
New Comment:
ORA-03120 has sometimes been seen with cross-version or cross-platform
Oracle connections. I think it might also have been seen in some
obscure case when the characters sets differed on the client and
server. Are you using a view or a dblink? Have you relinked PHP with
your most recent Oracle client libraries?
Maybe if you gave the Oracle version(s) and the datatype of the EMAIL
column someone else might be able to identify what it happening.
The comments in http://bugs.php.net/bug.php?id=19304 about contacting
Oracle Support and checking Metalink are good suggestions.
Previous Comments:
[2003-10-10 12:57:34] iolaire dot mckinnon at vcint dot com
Yes, the database is running on Solaris 8. As mentioned, there's no
problem with standard oracle, only OCI8.
[2003-10-10 11:46:23] [EMAIL PROTECTED]
See bug #19304. Is the remote oracle running on Solaris perhaps?
[2003-10-10 08:17:04] iolaire dot mckinnon at vcint dot com
I have the variables I'm putenv()ing there in SetEnv (httpd.conf) and
export (.bash_profile) as well. It hasn't made a difference. The oracle
is not running locally therefore the other comments regarding shared
oracle/httpd groups don't appear to apply in this case. I compiled
against Oracle 9r2.
[2003-10-10 06:57:03] [EMAIL PROTECTED]
Setting those environment variables in script is not gonna work, they
need to be set BEFORE apache/php is started.
[2003-10-10 05:32:15] iolaire dot mckinnon at vcint dot com
Description:
I'm using Redhat 9, connecting to a Oracle 8.7.1 db. I have the
following PHP configuration:
'./configure' '--with-iodbc' '--with-mssql=/usr/local'
'--sysconfdir=/etc' '--with-mysql' '--with-layout=GNU' '--with-gettext'
'--with-apxs2=/usr/local/apache2/bin/apxs'
'--with-config-file-path=/etc/' '--enable-ftp' '--enable-memory-limit'
'--enable-xslt' '--with-xslt-sablot' '--with-oracle=/store/OraHome1'
'--with-oci8=/store/OraHome1'
I connect successfully to the db using OCI8, but when I perform any
select, I get an "ORA-03120: two-task conversion routine: integer
overflow" error. This occurs even if I am only selecting one row. I can
successfully select using the same query with the standard Oracle
interface, and with SQLPlus. I also had this problem with php-4.3.2.
Reproduce code:
---
putenv("ORACLE_SID=REP");
putenv("ORACLE_HOME=/store/OraHome1");
putenv("TNS_ADMIN=/store/tnsnames.ora");
OCIInternalDebug(1);
$username = "MCKINNONI";
$passwd = "xxx";
$db="(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=)(PORT=1521)
)
)
(CONNECT_DATA=(SERVICE_NAME=REP))
)";
$conn = OCILogon($username,$passwd,$db);
$stmt = ociparse($conn,"select EMAIL from SpinroomEmailAddresses where
EMAIL = '[EMAIL PROTECTED]
int.com'");
ociexecute($stmt);
while (ocifetch($stmt))
echo "[".ociresult($stmt,"EMAIL")."]\n";
Expected result:
[EMAIL PROTECTED]
Actual result:
--
OCIDebug: _oci_open_server new conn=0 dname=(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=
(PROTOCOL=TCP)
(HOST=)(PORT=1521)
)
)
(CONNECT_DATA=(SERVICE_NAME=REP))
)
OCIDebug: _oci_open_session new sess=5 user=MCKINNONI
OCIDebug: oci_do_connect: id=6
OCIDebug: oci_parse "select EMAIL from SpinroomEmailAddresses where
EMAIL = '[EMAIL PROTECTED]'" id=7 conn=6
Warning: ociexecute(): OCIStmtExecute: ORA-03120: two-task conversion
routine: integer overflow
in /var/www/html/oracletest2.php on line 21
OCIDebug: START php_rshutdown_oci
OCIDebug: END php_rshutdown_oci
--
Edit this bug report at http://bugs.php.net/?id=25818&edit=1
#25123 [Com]: ocierror() returns always ORA-24315 illegal attribute type
ID: 25123
Comment by: cjbj at hotmail dot com
Reported By: karel dot miarka at issa dot cz
Status: Open
Bug Type: OCI8 related
Operating System: Windows 2000
PHP Version: 4.3.3RC5-dev, 5.0.0b2-dev
New Comment:
Does not reproduce for me with PHP 4.3.3 on W2K using Oracle 9.2.0.1.
Re SET AUTOTRACE, this is SQL*Plus specific and produces a simple
tuning report
I discovered PHP's OCI8 internal debug output can be enabled by calling
ociinternaldebug(1). Maybe this will help
the filer?
Previous Comments:
[2003-08-29 09:13:59] karel dot miarka at issa dot cz
I use Apache/1.3.24 for Windows 95/NT, and Oracle8 Release 8.0.5.0.0 -
Production on Linux, but it behaves the same also under Oracle 8.1 for
Windows.
Autotrace seems to be SQL*plus feature only and in addition it seems to
be off by default.
The ocierror() behaves fine under PHP 4.2 on Windows.
And there is no problem with ocierror() on Linux with PHP 4.3.3 .
I have reported this bug on "PHP 4.3.x" and someone else has changed
this my line to "4.3.3RC5-dev, 5.0.0b2-dev" so I guess this "unknown"
person is a PHP-OCI8 developer who reproduced this error with those PHP
version.
[2003-08-29 08:44:48] guenter_doge at web dot de
Could not reproduce this with PHP 4.3.3 & IIS 5.0 & win 2k & Oracle
8.1.7
One guess: Disable tracing in Oracle ("Set Autotrace Off") and try
again.
[2003-08-18 00:58:09] karel dot miarka at issa dot cz
Description:
ocierror() function:
1) returns ORA-24315 illegal attribute type
after any error. For example ociexcute() prints the valid error in
notice, but calling ocierror returns always ORA-24315 illegal attribute
type:
Warning: OCIStmtExecute: ORA-00942: table or view does not exist in
c:\www\ocierror_bug.php on line 20
ocierror($stmt): Array ( [code] => 24315 [message] => ORA-24315:
illegal attribute type [offset] => 17 [sqltext] => ) 1
2) doesn't return the sqltext item in the error array
The bug is in all PHP 4.3.x Windows versions.
3) invalid error offset returned
Reproduce code:
---
PHP ocierror() bug';
$conn = ocilogon('user', 'passwd', 'host');
// execute error BEGIN
$stmt = ociparse($conn, "SELECT xyz12345 FROM no_table123");
ociexecute($stmt);
echo 'ocierror($stmt): ', print_r(ocierror($stmt)), '';
ocifreestatement($stmt);
// execute error END
ocilogoff($conn);
?>
Expected result:
Warning: OCIStmtExecute: ORA-00942: table or view does not exist in
c:\www\ocierror_bug.php on line 20
ocierror($stmt): Array ( [code] => 942 [message] => ORA-00942: table or
view does not exist [offset] => 22 [sqltext] => SELECT xyz12345 FROM
no_table123) 1
Actual result:
--
Warning: OCIStmtExecute: ORA-00942: table or view does not exist in
c:\www\ocierror_bug.php on line 20
ocierror($stmt): Array ( [code] => 24315 [message] => ORA-24315:
illegal attribute type [offset] => 17 [sqltext] => ) 1
--
Edit this bug report at http://bugs.php.net/?id=25123&edit=1
#24980 [NEW]: Array_reduce uses first element as default running total
From: cjbj at hotmail dot com Operating system: Windows 2000 PHP version: 4.3.2 PHP Bug Type: Arrays related Bug description: Array_reduce uses first element as default running total Description: If the optional 'initial' parameter to array_reduce() is omitted, its default value is the first element of the array, and iteration proceeds over the second and subsequent array elements. This means that the first element may not have the "function" applied to it. Reproduce code: --- For example: Expected result: The expected output is: running_total is 0, current_value is 2 running_total is 4, current_value is 3 running_total is 13, current_value is 5 running_total is 38, current_value is 7 Total is 87 This calls add_up() once per array element. Actual result: -- The actual result is: running_total is 2, current_value is 3 running_total is 11, current_value is 5 running_total is 36, current_value is 7 Total is 85 Adding the optional third parameter to array_reduce(): $total = array_reduce($numbers, 'add_up', 0); gives the expected (and desired for the default case) output: running_total is 0, current_value is 2 running_total is 4, current_value is 3 running_total is 13, current_value is 5 running_total is 38, current_value is 7 Total is 87 This total is the sum of the squares. The uncomfirmed errata to Programming PHP (http://www.oreilly.com/catalog/progphp/errata/progphp.unconfirmed) indicates to me the default value of 'initial' may be a bug. If it is not a bug, then the current behavior doesn't seem to match common expectations and the manual entry "applies iteratively the function function to the elements of the array input" could be clarified. Tested on 4.3.2 on Windows 2000 with the prebuilt binary of 29 June 2003 from php.net. -- Edit bug report at http://bugs.php.net/?id=24980&edit=1 -- Try a CVS snapshot (php4): http://bugs.php.net/fix.php?id=24980&r=trysnapshot4 Try a CVS snapshot (php5): http://bugs.php.net/fix.php?id=24980&r=trysnapshot5 Fixed in CVS: http://bugs.php.net/fix.php?id=24980&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=24980&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=24980&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=24980&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=24980&r=support Expected behavior: http://bugs.php.net/fix.php?id=24980&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=24980&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=24980&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=24980&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=24980&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=24980&r=dst IIS Stability: http://bugs.php.net/fix.php?id=24980&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=24980&r=gnused
