Bug #52187 [Fbk->Opn]: apache2handler build error
Edit report at http://bugs.php.net/bug.php?id=52187&edit=1 ID: 52187 User updated by: maxim dot novozhilov at gmail dot com Reported by: maxim dot novozhilov at gmail dot com Summary: apache2handler build error -Status: Feedback +Status: Open Type: Bug Package: Apache2 related Operating System: FreeBSD 7.3-RELEASE (amd64) PHP Version: 5.2.13 New Comment: > Does this happen on 5.3.x? No, I compiled 5.3.2 from source w/o any problems. Previous Comments: [2010-06-26 23:24:00] ka...@php.net Does this happen on 5.3.x? Just wondering since we don't bundle the regex lib in the root anymore [2010-06-26 23:23:08] ka...@php.net Would something as simple as adding, between the two #include statements in mod_php5.c: #undef regoff_t [2010-06-26 00:12:06] maxim dot novozhilov at gmail dot com Description: Try ./configure --with-apxs2=/usr/local/sbin/apxs then `make` and you get always build error: previous declaration of 'regoff_t' was here The same for 5.2.14RC1 I have apache-2.0.63 installed on x64 system Actual result: -- /bin/sh /usr/home/max/dist/php-5.2.13/libtool --silent --preserve-dup-deps -- mode=compile gcc -DBIG_SECURITY_HOLE -I/usr/local/include/apache2 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/apr-0 -I/usr/local/include/apr-0 - I/usr/local/include -I/usr/local/include/db42 -Isapi/apache2handler/ - I/usr/home/max/dist/php-5.2.13/sapi/apache2handler/ -DPHP_ATOM_INC - I/usr/home/max/dist/php-5.2.13/include -I/usr/home/max/dist/php-5.2.13/main - I/usr/home/max/dist/php-5.2.13 -I/usr/home/max/dist/php-5.2.13/ext/date/lib - I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/max/dist/php- 5.2.13/TSRM -I/usr/home/max/dist/php-5.2.13/Zend-I/usr/local/include -g -O2 -c /usr/home/max/dist/php-5.2.13/sapi/apache2handler/mod_php5.c -o sapi/apache2handler/mod_php5.lo In file included from /usr/local/include/apache2/httpd.h:44, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/php_apache.h:24, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/mod_php5.c:26: /usr/local/include/apache2/ap_regex.h:90: error: conflicting types for 'regoff_t' /usr/home/max/dist/php-5.2.13/regex/regex.h:17: error: previous declaration of 'regoff_t' was here *** Error code 1 -- Edit this bug report at http://bugs.php.net/bug.php?id=52187&edit=1
[PHP-BUG] Bug #52187 [NEW]: build error
From: Operating system: FreeBSD 7.3-RELEASE (amd64) PHP version: 5.2.13 Package: *General Issues Bug Type: Bug Bug description:build error Description: Try ./configure --with-apxs2=/usr/local/sbin/apxs then `make` and you get always build error: previous declaration of 'regoff_t' was here The same for 5.2.14RC1 I have apache-2.0.63 installed on x64 system Actual result: -- /bin/sh /usr/home/max/dist/php-5.2.13/libtool --silent --preserve-dup-deps -- mode=compile gcc -DBIG_SECURITY_HOLE -I/usr/local/include/apache2 -D_REENTRANT -D_THREAD_SAFE -I/usr/local/include/apr-0 -I/usr/local/include/apr-0 - I/usr/local/include -I/usr/local/include/db42 -Isapi/apache2handler/ - I/usr/home/max/dist/php-5.2.13/sapi/apache2handler/ -DPHP_ATOM_INC - I/usr/home/max/dist/php-5.2.13/include -I/usr/home/max/dist/php-5.2.13/main - I/usr/home/max/dist/php-5.2.13 -I/usr/home/max/dist/php-5.2.13/ext/date/lib - I/usr/local/include/libxml2 -I/usr/local/include -I/usr/home/max/dist/php- 5.2.13/TSRM -I/usr/home/max/dist/php-5.2.13/Zend-I/usr/local/include -g -O2 -c /usr/home/max/dist/php-5.2.13/sapi/apache2handler/mod_php5.c -o sapi/apache2handler/mod_php5.lo In file included from /usr/local/include/apache2/httpd.h:44, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/php_apache.h:24, from /usr/home/max/dist/php- 5.2.13/sapi/apache2handler/mod_php5.c:26: /usr/local/include/apache2/ap_regex.h:90: error: conflicting types for 'regoff_t' /usr/home/max/dist/php-5.2.13/regex/regex.h:17: error: previous declaration of 'regoff_t' was here *** Error code 1 -- Edit bug report at http://bugs.php.net/bug.php?id=52187&edit=1 -- Try a snapshot (PHP 5.2): http://bugs.php.net/fix.php?id=52187&r=trysnapshot52 Try a snapshot (PHP 5.3): http://bugs.php.net/fix.php?id=52187&r=trysnapshot53 Try a snapshot (trunk): http://bugs.php.net/fix.php?id=52187&r=trysnapshottrunk Fixed in SVN: http://bugs.php.net/fix.php?id=52187&r=fixed Fixed in SVN and need be documented: http://bugs.php.net/fix.php?id=52187&r=needdocs Fixed in release: http://bugs.php.net/fix.php?id=52187&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=52187&r=needtrace Need Reproduce Script: http://bugs.php.net/fix.php?id=52187&r=needscript Try newer version: http://bugs.php.net/fix.php?id=52187&r=oldversion Not developer issue: http://bugs.php.net/fix.php?id=52187&r=support Expected behavior: http://bugs.php.net/fix.php?id=52187&r=notwrong Not enough info: http://bugs.php.net/fix.php?id=52187&r=notenoughinfo Submitted twice: http://bugs.php.net/fix.php?id=52187&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=52187&r=globals PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52187&r=php4 Daylight Savings:http://bugs.php.net/fix.php?id=52187&r=dst IIS Stability: http://bugs.php.net/fix.php?id=52187&r=isapi Install GNU Sed: http://bugs.php.net/fix.php?id=52187&r=gnused Floating point limitations: http://bugs.php.net/fix.php?id=52187&r=float No Zend Extensions: http://bugs.php.net/fix.php?id=52187&r=nozend MySQL Configuration Error: http://bugs.php.net/fix.php?id=52187&r=mysqlcfg
#43038 [Asn]: Memory Allocaltion Failure on versions 5.2.1 and up
ID: 43038 User updated by: mike dot simonds at maxim-ic dot com Reported By: mike dot simonds at maxim-ic dot com Status: Assigned Bug Type: SOAP related Operating System: * PHP Version: 5.2CVS-2007-10-22 Assigned To: dmitry New Comment: I have finally gathered all the scripts into one package and emailed Dmitry the zip file to be able to reproduce the error Previous Comments: [2007-10-29 11:41:46] mike dot simonds at maxim-ic dot com Dmitry I have been in contact with Salesforce support and they are going to temporarily assign me an instance so I can reproduce the error. I am should have an area loaded today with bogus records to test the extract and reproduce the error today. I will then email you the scripts that cause the error ~Mike [2007-10-25 14:43:01] mike dot simonds at maxim-ic dot com I wanted to explain to you the reasoning why I cannot 1) give you access to the area where this error is occurring, and 2) why I cannot create a functional script without a user and password. 1) these scripts contain and retrieve company sensitive data and I do not have the authority to be able to let you have access to this data. 2) The script(s) work with Salesforce.com's API and it is necessary to have an ID and Password to login I have a meeting today with Salesforce to discuss the possibility of setting up some sort of test area to be able to replicate this error. I can however, and if you agree, send you some links to two identical servers. One server will run php 5.2.0 and an export script and work just fine. One server will be running the latest CVS version of PHP 5.2.4 and will error. I cannot post these two URL's in the Bug due to private addresses. Please let me know if this can be done I will post this in the bug to keep it updated [2007-10-24 17:32:32] mike dot simonds at maxim-ic dot com Dmitry Thanks for the quick response. There is no way that I can write a script that allows access to this data without giving you access to the script, password & username, or our salesforce.com instance. I am in contact with the developers over at salesforce now trying to get access to a testing area where I can reproduce this error. The data that is being accessed is sensitive data from my organization. I can however send you a link so you can run the script and see the error from the exact script that I posted in the orignial post Sorry for this sir! Regards, Mike [2007-10-24 06:28:07] [EMAIL PROTECTED] Sorry, but could you please provide a complete example that demonstrates the bug and doesn't require your password. [2007-10-23 09:26:17] [EMAIL PROTECTED] Assigned to the SOAP extension maintainer. 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/43038 -- Edit this bug report at http://bugs.php.net/?id=43038&edit=1
#43038 [Asn]: Memory Allocaltion Failure on versions 5.2.1 and up
ID: 43038 User updated by: mike dot simonds at maxim-ic dot com Reported By: mike dot simonds at maxim-ic dot com Status: Assigned Bug Type: SOAP related Operating System: * PHP Version: 5.2CVS-2007-10-22 Assigned To: dmitry New Comment: Dmitry I have been in contact with Salesforce support and they are going to temporarily assign me an instance so I can reproduce the error. I am should have an area loaded today with bogus records to test the extract and reproduce the error today. I will then email you the scripts that cause the error ~Mike Previous Comments: [2007-10-25 14:43:01] mike dot simonds at maxim-ic dot com I wanted to explain to you the reasoning why I cannot 1) give you access to the area where this error is occurring, and 2) why I cannot create a functional script without a user and password. 1) these scripts contain and retrieve company sensitive data and I do not have the authority to be able to let you have access to this data. 2) The script(s) work with Salesforce.com's API and it is necessary to have an ID and Password to login I have a meeting today with Salesforce to discuss the possibility of setting up some sort of test area to be able to replicate this error. I can however, and if you agree, send you some links to two identical servers. One server will run php 5.2.0 and an export script and work just fine. One server will be running the latest CVS version of PHP 5.2.4 and will error. I cannot post these two URL's in the Bug due to private addresses. Please let me know if this can be done I will post this in the bug to keep it updated [2007-10-24 17:32:32] mike dot simonds at maxim-ic dot com Dmitry Thanks for the quick response. There is no way that I can write a script that allows access to this data without giving you access to the script, password & username, or our salesforce.com instance. I am in contact with the developers over at salesforce now trying to get access to a testing area where I can reproduce this error. The data that is being accessed is sensitive data from my organization. I can however send you a link so you can run the script and see the error from the exact script that I posted in the orignial post Sorry for this sir! Regards, Mike [2007-10-24 06:28:07] [EMAIL PROTECTED] Sorry, but could you please provide a complete example that demonstrates the bug and doesn't require your password. [2007-10-23 09:26:17] [EMAIL PROTECTED] Assigned to the SOAP extension maintainer. [2007-10-22 13:21:50] mike dot simonds at maxim-ic dot com We tried a CVS version for both Linux and Windows on Sunday and still received the same error/fault Thanks, Mike 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/43038 -- Edit this bug report at http://bugs.php.net/?id=43038&edit=1
#43038 [Fbk->Opn]: Memory Allocaltion Failure on versions 5.2.1 and up
ID: 43038 User updated by: mike dot simonds at maxim-ic dot com Reported By: mike dot simonds at maxim-ic dot com -Status: Feedback +Status: Open Bug Type: SOAP related Operating System: Windows XP & Linux PHP Version: 5.2CVS-2007-10-22 Assigned To: dmitry New Comment: I wanted to explain to you the reasoning why I cannot 1) give you access to the area where this error is occurring, and 2) why I cannot create a functional script without a user and password. 1) these scripts contain and retrieve company sensitive data and I do not have the authority to be able to let you have access to this data. 2) The script(s) work with Salesforce.com's API and it is necessary to have an ID and Password to login I have a meeting today with Salesforce to discuss the possibility of setting up some sort of test area to be able to replicate this error. I can however, and if you agree, send you some links to two identical servers. One server will run php 5.2.0 and an export script and work just fine. One server will be running the latest CVS version of PHP 5.2.4 and will error. I cannot post these two URL's in the Bug due to private addresses. Please let me know if this can be done I will post this in the bug to keep it updated Previous Comments: [2007-10-24 17:32:32] mike dot simonds at maxim-ic dot com Dmitry Thanks for the quick response. There is no way that I can write a script that allows access to this data without giving you access to the script, password & username, or our salesforce.com instance. I am in contact with the developers over at salesforce now trying to get access to a testing area where I can reproduce this error. The data that is being accessed is sensitive data from my organization. I can however send you a link so you can run the script and see the error from the exact script that I posted in the orignial post Sorry for this sir! Regards, Mike [2007-10-24 06:28:07] [EMAIL PROTECTED] Sorry, but could you please provide a complete example that demonstrates the bug and doesn't require your password. [2007-10-23 09:26:17] [EMAIL PROTECTED] Assigned to the SOAP extension maintainer. [2007-10-22 13:21:50] mike dot simonds at maxim-ic dot com We tried a CVS version for both Linux and Windows on Sunday and still received the same error/fault Thanks, Mike [2007-10-22 08:15:14] [EMAIL PROTECTED] Please try using this CVS snapshot: http://snaps.php.net/php5.2-latest.tar.gz For Windows (zip): http://snaps.php.net/win32/php5.2-win32-latest.zip For Windows (installer): http://snaps.php.net/win32/php5.2-win32-installer-latest.msi 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/43038 -- Edit this bug report at http://bugs.php.net/?id=43038&edit=1
#43038 [Fbk->Opn]: Memory Allocaltion Failure on versions 5.2.1 and up
ID: 43038
User updated by: mike dot simonds at maxim-ic dot com
Reported By: mike dot simonds at maxim-ic dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Windows XP & Linux
PHP Version: 5.2CVS-2007-10-22
Assigned To: dmitry
New Comment:
Dmitry
Thanks for the quick response. There is no way that I can write a
script that allows access to this data without giving you access to the
script, password & username, or our salesforce.com instance. I am in
contact with the developers over at salesforce now trying to get access
to a testing area where I can reproduce this error. The data that is
being accessed is sensitive data from my organization. I can however
send you a link so you can run the script and see the error from the
exact script that I posted in the orignial post
Sorry for this sir!
Regards,
Mike
Previous Comments:
[2007-10-24 06:28:07] [EMAIL PROTECTED]
Sorry, but could you please provide a complete example that
demonstrates the bug and doesn't require your password.
[2007-10-23 09:26:17] [EMAIL PROTECTED]
Assigned to the SOAP extension maintainer.
[2007-10-22 13:21:50] mike dot simonds at maxim-ic dot com
We tried a CVS version for both Linux and Windows on Sunday and still
received the same error/fault
Thanks,
Mike
[2007-10-22 08:15:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-10-19 14:00:10] mike dot simonds at maxim-ic dot com
Description:
I have a set of scripts which connect to Salesforce.com's API and
retrieve data from our instance and stores them in either an Oracle
Database or MySQL. These scripts are identical, just the retrieving SQL
statement is different. The Memory leak error happens when the scripts
with large data sets perform the extract. The reason that I am
reporting this bug is that these scripts performed flawlessly in all php
version 5.* prior to upgrading to 5.2.1 and up. The servers that house
these scripts are currently running 5.2.0
Reproduce code:
---
source of code > http://www.mikesimonds.com/soap_php_bug.phps
Expected result:
I expected the data to be retrieved and inserted into our target
database without any errors as it did with versions prior to 5.2.1.
These data sets number in the 130,000 count and have 40-60 rows in each
table
Actual result:
--
Error Results:
Fatal error: Uncaught SoapFault exception: [Client] Allowed memory size
of 134217728 bytes exhausted (tried to allocate 1856074 bytes) in
C:\wamp\www\includes\soapclient\SforceBaseClient.php:506 Stack trace: #0
[internal function]: SoapClient->__call('queryMore', Array) #1
C:\wamp\www\includes\soapclient\SforceBaseClient.php(506):
SoapClient->queryMore(Object(stdClass)) #2
C:\wamp\www\extract\export_product2.php(122):
SforceBaseClient->queryMore('01g4001pM0w...') #3
C:\wamp\www\extract\export_product2.php(28):
get_products(Object(SforcePartnerClient)) #4 {main} thrown in
C:\wamp\www\includes\soapclient\SforceBaseClient.php on line 506
--
Edit this bug report at http://bugs.php.net/?id=43038&edit=1
#43038 [Fbk->Opn]: Memory Allocaltion Failure on versions 5.2.1 and up
ID: 43038
User updated by: mike dot simonds at maxim-ic dot com
Reported By: mike dot simonds at maxim-ic dot com
-Status: Feedback
+Status: Open
Bug Type: SOAP related
Operating System: Windows XP & Linux
PHP Version: 5.2.4
New Comment:
We tried a CVS version for both Linux and Windows on Sunday and still
received the same error/fault
Thanks,
Mike
Previous Comments:
[2007-10-22 08:15:14] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5.2-latest.tar.gz
For Windows (zip):
http://snaps.php.net/win32/php5.2-win32-latest.zip
For Windows (installer):
http://snaps.php.net/win32/php5.2-win32-installer-latest.msi
[2007-10-19 14:00:10] mike dot simonds at maxim-ic dot com
Description:
I have a set of scripts which connect to Salesforce.com's API and
retrieve data from our instance and stores them in either an Oracle
Database or MySQL. These scripts are identical, just the retrieving SQL
statement is different. The Memory leak error happens when the scripts
with large data sets perform the extract. The reason that I am
reporting this bug is that these scripts performed flawlessly in all php
version 5.* prior to upgrading to 5.2.1 and up. The servers that house
these scripts are currently running 5.2.0
Reproduce code:
---
source of code > http://www.mikesimonds.com/soap_php_bug.phps
Expected result:
I expected the data to be retrieved and inserted into our target
database without any errors as it did with versions prior to 5.2.1.
These data sets number in the 130,000 count and have 40-60 rows in each
table
Actual result:
--
Error Results:
Fatal error: Uncaught SoapFault exception: [Client] Allowed memory size
of 134217728 bytes exhausted (tried to allocate 1856074 bytes) in
C:\wamp\www\includes\soapclient\SforceBaseClient.php:506 Stack trace: #0
[internal function]: SoapClient->__call('queryMore', Array) #1
C:\wamp\www\includes\soapclient\SforceBaseClient.php(506):
SoapClient->queryMore(Object(stdClass)) #2
C:\wamp\www\extract\export_product2.php(122):
SforceBaseClient->queryMore('01g4001pM0w...') #3
C:\wamp\www\extract\export_product2.php(28):
get_products(Object(SforcePartnerClient)) #4 {main} thrown in
C:\wamp\www\includes\soapclient\SforceBaseClient.php on line 506
--
Edit this bug report at http://bugs.php.net/?id=43038&edit=1
#43038 [NEW]: Memory Allocaltion Failure on versions 5.2.1 and up
From: mike dot simonds at maxim-ic dot com
Operating system: Windows XP & Linux
PHP version: 5.2.4
PHP Bug Type: SOAP related
Bug description: Memory Allocaltion Failure on versions 5.2.1 and up
Description:
I have a set of scripts which connect to Salesforce.com's API and retrieve
data from our instance and stores them in either an Oracle Database or
MySQL. These scripts are identical, just the retrieving SQL statement is
different. The Memory leak error happens when the scripts with large data
sets perform the extract. The reason that I am reporting this bug is that
these scripts performed flawlessly in all php version 5.* prior to
upgrading to 5.2.1 and up. The servers that house these scripts are
currently running 5.2.0
Reproduce code:
---
source of code > http://www.mikesimonds.com/soap_php_bug.phps
Expected result:
I expected the data to be retrieved and inserted into our target database
without any errors as it did with versions prior to 5.2.1. These data sets
number in the 130,000 count and have 40-60 rows in each table
Actual result:
--
Error Results:
Fatal error: Uncaught SoapFault exception: [Client] Allowed memory size of
134217728 bytes exhausted (tried to allocate 1856074 bytes) in
C:\wamp\www\includes\soapclient\SforceBaseClient.php:506 Stack trace: #0
[internal function]: SoapClient->__call('queryMore', Array) #1
C:\wamp\www\includes\soapclient\SforceBaseClient.php(506):
SoapClient->queryMore(Object(stdClass)) #2
C:\wamp\www\extract\export_product2.php(122):
SforceBaseClient->queryMore('01g4001pM0w...') #3
C:\wamp\www\extract\export_product2.php(28):
get_products(Object(SforcePartnerClient)) #4 {main} thrown in
C:\wamp\www\includes\soapclient\SforceBaseClient.php on line 506
--
Edit bug report at http://bugs.php.net/?id=43038&edit=1
--
Try a CVS snapshot (PHP 4.4):
http://bugs.php.net/fix.php?id=43038&r=trysnapshot44
Try a CVS snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=43038&r=trysnapshot52
Try a CVS snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=43038&r=trysnapshot53
Try a CVS snapshot (PHP 6.0):
http://bugs.php.net/fix.php?id=43038&r=trysnapshot60
Fixed in CVS: http://bugs.php.net/fix.php?id=43038&r=fixedcvs
Fixed in release:
http://bugs.php.net/fix.php?id=43038&r=alreadyfixed
Need backtrace: http://bugs.php.net/fix.php?id=43038&r=needtrace
Need Reproduce Script:http://bugs.php.net/fix.php?id=43038&r=needscript
Try newer version:http://bugs.php.net/fix.php?id=43038&r=oldversion
Not developer issue: http://bugs.php.net/fix.php?id=43038&r=support
Expected behavior:http://bugs.php.net/fix.php?id=43038&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=43038&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=43038&r=submittedtwice
register_globals: http://bugs.php.net/fix.php?id=43038&r=globals
PHP 3 support discontinued: http://bugs.php.net/fix.php?id=43038&r=php3
Daylight Savings: http://bugs.php.net/fix.php?id=43038&r=dst
IIS Stability:http://bugs.php.net/fix.php?id=43038&r=isapi
Install GNU Sed: http://bugs.php.net/fix.php?id=43038&r=gnused
Floating point limitations: http://bugs.php.net/fix.php?id=43038&r=float
No Zend Extensions: http://bugs.php.net/fix.php?id=43038&r=nozend
MySQL Configuration Error:http://bugs.php.net/fix.php?id=43038&r=mysqlcfg
#30804 [Asn]: multiple returned lob resource being overwritten
ID: 30804
Updated by: [EMAIL PROTECTED]
Reported By: michael dot caplan at lechateau dot ca
Status: Assigned
Bug Type: OCI8 related
Operating System: RHE 3
PHP Version: 5CVS-2005-04-05
Assigned To: tony2001
New Comment:
Well,
echo $row['CLOB_TEXT']->load();
is not exactly the same as
$res[] = $row['CLOB_TEXT'];
In the last one you are assigning the whole object to an element of an
array. This may be the reason it overwrites all the rest.
Try this:
$res[] = $row['CLOB_TEXT']->load();
and the print as
foreach($res as $r) {
echo $r . "\r\n";
}
Just my guess.
maxim
Previous Comments:
[2005-04-06 21:35:25] michael dot caplan at lechateau dot ca
It was a little difficult to test -- php kept on segfaulting with the
DB abstraction lib I normaily use. I tried a new test as follows, but
unfortunately I had the same results:
CREATE TABLE "INTRANET"."CLOB_TEST"
("ID" NUMBER NOT NULL ENABLE,
"TEXT_TEXT" VARCHAR2(500) NOT NULL ENABLE,
"CLOB_TEXT" CLOB,
PRIMARY KEY ("ID")
)
ID TEXT_TEXT CLOB_TEXT
-- - -
1 text1 this is a clob of text1
2 text2 this is a clob of text2
3 text3 this is a clob of text3
4 text4 this is a clob of text4
5 text5 this is a clob of text5
load() . "\r\n";
}
echo "2-\r\n";
$stmt = ociparse($db, $query);
ociexecute($stmt);
$res = array();
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
$res[] = $row['CLOB_TEXT'];
}
foreach($res as $r) {
echo $r->load() . "\r\n";
}
?>
results:
1
text1
this is a clob of text1
2
text2
this is a clob of text2
3
text3
this is a clob of text3
4
text4
this is a clob of text4
5
text5
this is a clob of text5
2-
this is a clob of text5
this is a clob of text5
this is a clob of text5
this is a clob of text5
this is a clob of text5
[2004-11-16 14:48:26] michael dot caplan at lechateau dot ca
Description:
I'm not 100% sure if this is a bug, or just a 'quirk', but my attempt
to get feedback on this issue on the php db support list was
unsuccessful. So, here I am
I am selecting multiple columns from a table, one being a clob. the
query returns multiple records for the query. The results are all
good, execpt the clob column in certain circumstances.
Normally, with such a db return, I would loop through the results and
grab the clobs one by one. Under 'special' circumstances, I would want
to first loop throught the results and assign the results to a new array
before fetching the clob. This is where things get funky. In this
senario, the last returned record's clob column overwrites all previous
clob columns (all the previous records have there unique data, except
the clob columns which contains the data for the last record across all
previous records).
A working example:
$query = 'select
id,
author,
cdate,
views,
title,
message,
top
from
APP_THREADS
where
TYPE = \'D\'';
$stmt = ociparse($fw_db->connection, $query);
ociexecute($stmt);
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
echo $row['MESSAGE']->load();
echo $row['id'];
// etc
}
as expected, I get all clobs from the result set. But in this example,
I do not:
$query = 'select
id,
author,
cdate,
views,
title,
message,
top
from
APP_THREADS
where
TYPE = \'D\'';
$stmt = ociparse($fw_db->connection, $query);
ociexecute($stmt);
while (OCIFetchInto ($stmt, $row, OCI_ASSOC)) {
// assign all lob resources to array for later loading
$messages[] = $row['MESSAGE'];
}
foreach ($messages as $message) {
echo $message->load();
}
In this example, the last assigned lob resource overwrites all previous
lob resources. When fetching the clob content later on, each record
returns the data from the last lob.
I am pretty unawair of the internal mechanics of how resources are
handled, and this just might be a quirk of how db result resources for
oci8 are handled, and is unavoidable. (it looks like one resource is
returned for all lobs, not multiple resources for each lob).
However, it is a pretty counter intuitive 'quirk'. If I can loop
through the results and assig
#34005 [Asn]: ocipasswordchange() fails
ID: 34005 Updated by: [EMAIL PROTECTED] Reported By: uherj at avx dot cz Status: Assigned Bug Type: OCI8 related Operating System: * PHP Version: 5CVS, 4CVS (2005-12-25) (snap) Assigned To: tony2001 New Comment: Hi, I heard about this very problem from my collegue just the other day. The weird fact is that I actually have added OCIPasswordChange() function myself yet in PHP v4.3.2 ad it really is a straight-forward function - it simply passes the data from and to OCI's OCIPasswordChange call. So there is no interacion with the data submitted. I still have no clear solution but I am guessing that this may relay to OCI itself, not really PHP's OCI8 extension. Anyone has any ideas? ORA-28002 is simply a warning that that your old password is about to expire, cant' there be something set for you that disallows you to change the password during the Grace Period? Did you try changing the password in PL/SQL to see if it's doable for your case? Are there any funny characters in your old password that can be interpreted wrongly? If so, try replicating the problem with a password made of [a-z0-9] and see if problem persists.. Nothing else comes to my mind Let me know. maxim Previous Comments: [2006-01-05 23:55:07] [EMAIL PROTECTED] No. Feel free to provide one. [2006-01-05 23:40:48] gcombe at co dot weber dot ut dot us so is there a fix for this or not? [2005-12-26 17:26:27] [EMAIL PROTECTED] Assuming this happens also with new oci code. [2005-08-05 13:40:04] uherj at avx dot cz this bug shows only when user account return warning: Warning: ocilogon(): OCISessionBegin: OCI_SUCCESS_WITH_INFO: ORA-28002: the password will expire within 10 day [2005-08-05 10:54:46] [EMAIL PROTECTED] FYI ocipasswordchange() passes correct string to OCI funcs. No idea why it fails. 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/34005 -- Edit this bug report at http://bugs.php.net/?id=34005&edit=1
#26286 [Com]: Parent: child process exited with status 3221225477 -- Restarting
ID: 26286 Comment by: maxim at am dot id dot lv Reported By: igg10 at alu dot ua dot es Status: No Feedback Bug Type: Apache2 related Operating System: Windows 2000 PHP Version: 4.3.4 New Comment: It`s not apache or php bug. It`s your own bug. Some where in your code you have cycle which never ends. Look through your code and you will find the error. Previous Comments: [2005-05-30 09:10:14] mail at fabianhess dot de I'm experiencing the problem when accessing an Oracle Database. The Apache Log says: [client 192.168.101.19] PHP Warning: ociserverversion() [function.ociserverversion]: OCIServerVersion: ORA-03113: Unerwartetes \xdcbertragungsende in Kommunikation\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 179 [client 192.168.101.19] PHP Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-03114: Nicht mit ORACLE verbunden\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 308 [client 192.168.101.19] PHP Warning: ociserverversion() [function.ociserverversion]: OCIServerVersion: ORA-01041: Interner Fehler: hostdef-Erweiterung ist nicht vorhanden\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 179 [client 192.168.101.19] PHP Warning: ociexecute() [function.ociexecute]: OCIStmtExecute: ORA-03114: Nicht mit ORACLE verbunden\n in C:\\Programme\\TSW\\Apache2\\intranet\\Maka\\orasql\\taskAusfuehren.php on line 308 [Thu May 26 01:50:06 2005] [notice] Parent: child process exited with status 3221225477 -- Restarting. [2003-11-17 14:18:03] [EMAIL PROTECTED] Not enough information was provided for us to be able to handle this bug. Please re-read the instructions at http://bugs.php.net/how-to-report.php If you can provide more information, feel free to add it to this bug and change the status back to "Open". Thank you for your interest in PHP. [2003-11-17 07:51:17] igg10 at alu dot ua dot es Description: Apache2 crashes PHP as module on apache 2.0.47 php 4.3.2 windows 2000 Fri Nov 14 12:53:09 2003] [notice] Parent: child process exited with status 3221225477 -- Restarting. [Fri Nov 14 12:53:09 2003] [notice] Parent: Created child process 1044 [Fri Nov 14 12:53:09 2003] [notice] Child 1044: Child process is running [Fri Nov 14 12:53:10 2003] [notice] Child 1044: Acquired the start mutex. [Fri Nov 14 12:53:10 2003] [notice] Child 1044: Starting 64 worker threads. -- Edit this bug report at http://bugs.php.net/?id=26286&edit=1
#28029 [Com]: HTTP request failed!
ID: 28029
Comment by: maxim at enelis dot ru
Reported By: coadmin at hostings dot pl
Status: No Feedback
Bug Type: URL related
Operating System: FreeBSD 4.9 and 5.2.1
PHP Version: 4CVS-2004-04-16 (stable)
New Comment:
Have the same problem on FreeBSD 5.3 Release. + Apache 2.0.48 or 2.0.52
+ PHP 4.3.8 + 4.3.9 + 4.3.10
--enable-debug doesn't solve the problem. Using --disable-all can't be
done because this is a production host. It worked without any problems
until last days. And right now fopen http doesnt work at all.
Have tested the same on FreeBSD 4.9 + Apache 2.0.48 + PHP 4.3.10. Works
correct with no problems.
The server where we catch this bug hosts about 500 virtualhosts.
code:
http://ya.ru","r";);
fpassthru($r);
fclose($r);
?>
--
error:
Warning: fopen(http://ya.ru/): failed to open stream: HTTP request
failed! in /home/test/www/test2.php on line 6
--
Sometimes after "HTTP request failed!" there are some unreadable chars
as "".
Previous Comments:
[2004-11-10 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".
[2004-11-02 10:41:52] [EMAIL PROTECTED]
Please try using this CVS snapshot:
http://snaps.php.net/php5-STABLE-latest.tar.gz
For Windows:
http://snaps.php.net/win32/php5.0-win32-latest.zip
If using fsockopen and friends on servers with large numbers of error
logs configured and seeing memory corruption bugs or otherwise, then
that's bug 24189 - select vs FD_SETSIZE issues.
This is fixed for future 5.0.x releases (all praise Wez!), so try a
5.0.x snapshot. Bugs in Fedora Core or RHEL PHP packages should be
reported to https://bugzilla.redhat.com/bugzilla/.
[2004-11-01 15:51:16] tongsam at 126 dot com
I'v this problem too, on apache started a few hours, the logs:
kernel: pid 65604 (httpd), uid 1011: exited on signal 11
Freebsd 4.9 + Apache 2.0.52 + php 4.3.9
[2004-10-08 01:02:52] joseph at digiweb dot net dot nz
Apache 2.0.46
PHP 4.3.2
Redhat Enterprise 3.0
We were seeing very similar behaviour to this with fopen, getimagesize,
etc, however, we were not experiencing any segfaults.
What we found was that first, the number of VirtualHosts we had defined
would affect the behaviour of this bug: If we had more than 502
virtualhosts, the fopen HTTP requests would fail, if we had 502 or
less, they would work correctly.
We thought it might have something to do with the number of open file
handles, but as far as we could tell, we were well clear of these
limits.
Then (basically by accident) we worked out that if we had each
VirtualHost use the same, global "ErrorLog" file, the problem went
away, as opposed to the situation before when we had seperate error
logs for each virtualhost.
We also had another test box, running Fedora Core 2, Apache 2.0.51, and
PHP 5.02, on which we were unable to reproduce the problem.
I hope this might possibly shed some light on things.
[2004-09-02 00:02:10] maximander at gmail dot com
this has been happening to my site too.
the following code errors, as does almost any use of
file(),fopen(),file_get_contents() or readfile() on remote files.
fsockopen seems to work for now though.
http://gerpok.darkflux.com/write.php";);
if(strpos($file[0],"you don't")) { echo "not updated";}
?>
and, whats more, after a recompile with --enable-debug, it is still
error'ing. anything useful we can do with a debug build that errors on
a regular basis?
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/28029
--
Edit this bug report at http://bugs.php.net/?id=28029&edit=1
#22724 [Opn->Fbk]: OCIParse: ORA-00001
ID: 22724 Updated by: [EMAIL PROTECTED] Reported By: admin at iut-info dot ens dot univ-reims dot fr -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: HP-UX 11.11 PHP Version: 4.3.2RC1 New Comment: Thank you for this bug report. To properly diagnose the problem, we need a backtrace to see what is happening behind the scenes. To find out how to generate a backtrace, please read http://bugs.php.net/bugs-generating-backtrace.php Once you have generated a backtrace, please submit it to this bug report and change the status back to "Open". Thank you for helping us make PHP better. can you try to do the same test with the code that has OCIInternalDebug(1); function on top. Please post the output here. Previous Comments: [2003-03-15 03:51:53] admin at iut-info dot ens dot univ-reims dot fr - CONFIGURE -- ./configure \ --with-oci8 \ --with-apache=../apache_1.3.27 \ --with-gd \ --with-pdflib=/opt/pdflib \ --with-jpeg-dir \ --with-png-dir \ --with-tiff-dir \ --with-zlib \ --with-bz2 \ --enable-sigchild \ --with-mysql=/opt/mysql4\ --with-pgsql=/opt/pgsql \ --with-tsrm-pthreads\ --with-dom \ --enable-ftp\ --enable-sockets - testoci8.php -- Test de connexion PHP - Oracle 8i $nrows Records Selected\n"; } OCILogOff($conn); } elseecho " OCILogon ERREUR\n"; ?> Result with PHP-4.3.0 --- OCILogon Ok Server Version: Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production JServer Release 8.1.7.0.0 - Production 2 Records Selected Result with PHP-4.3.2 - OCILogon Ok Server Version: Oracle8i Enterprise Edition Release 8.1.7.0.0 - Production JServer Release 8.1.7.0.0 - Production Warning: ociparse() [function.ociparse]: OCIParse: ORA-1: unique constraint (%s.%s) violated in /home/prof/collet/public_html/testoci8.php on line 12 Warning: ociexecute(): supplied argument is not a valid OCI8-Statement resource in /home/prof/collet/public_html/testoci8.php on line 13 -- Cordialy. -- Edit this bug report at http://bugs.php.net/?id=22724&edit=1
#22106 [NoF->Csd]: Segmentation fault and IMAP
ID: 22106 User updated by: maxim at wl dot dn dot ua Reported By: maxim at wl dot dn dot ua -Status: No Feedback +Status: Closed Bug Type: IMAP related Operating System: RedHat Linux 7.2 -PHP Version: 4.3.1-dev +PHP Version: 4.3.0 New Comment: Thank you for your advices. I have solved this problem upgrading Apache to 2.0.44 and compiling PHP with this configuration line: --with-apxs2=/usr/local/apache2/bin/apxs2. In Apache 1.3.27 segmentation fault was appear when I compiled PHP with PostgreSQL and IMAP support. And now all works perfectly. Previous Comments: [2003-02-20 08:10:33] [EMAIL PROTECTED] No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Open". Thank you. [2003-02-07 06:46:37] [EMAIL PROTECTED] Using '/usr/local/lib' for any configure option is wrong. Use '/usr/local' instead. (this can not cause the problem though) And to get the backtrace for the crash: (gdb) run -X (gdb) bt Please try minimizing the configure options and try this configure line for PHP: ./configure --disable-all --with-apache=../apache_1.3.27 --with-imap=/usr/local --with-kerberos ---- [2003-02-07 05:43:30] maxim at wl dot dn dot ua Hello! I can't run httpd with mod_php4/IMAP support. Config lines there are: PHP - ./configure' --with-zlib --with-pgsql=/usr/local/pgsql --with-layout=GNU --with-dom=/usr/local/lib --without-mysql --with-imap=/usr/local --with-kerberos=/usr/local --with-xslt-sablot --enable-xslt --with-iconv=/usr/local/lib/ --with-curl=/usr/local/lib --with-apache=../apache_1.3.27 --enable-calendar --with-gettext=/bin --with-ming=/usr/lib --with-gd --enable-gd-native-ttf --with-png-dir=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr/local --with-bz2 --enable-debug=yes Apache - SSL_BASE="/usr/src/openssl-0.9.6b" ./configure --with-layout=RedHat --enable-module=so --enable-module=auth --enable-module=ssl --enable-module=proxy --activate-module=src/modules/php4/libphp4.a All things compiled successfully, but when I tried to run httpd with gdb, I get the following message: (gdb) run -X Starting program: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x084c8100 in ?? () at eval.c:41 41 eval.c: No such file or directory. in eval.c When I compiled this without IMAP support, all works perfectly. php4-STABLE-200302071030 apache 1.3.27 imap-2001a-10 -- Edit this bug report at http://bugs.php.net/?id=22106&edit=1
#22106 [NEW]: Segmentation fault and IMAP
From: [EMAIL PROTECTED] Operating system: RedHat Linux 7.2 PHP version: 4.3.0 PHP Bug Type: IMAP related Bug description: Segmentation fault and IMAP Hello! I can't run httpd with mod_php4/IMAP support. Config lines there are: PHP - ./configure' --with-zlib --with-pgsql=/usr/local/pgsql --with-layout=GNU --with-dom=/usr/local/lib --without-mysql --with-imap=/usr/local --with-kerberos=/usr/local --with-xslt-sablot --enable-xslt --with-iconv=/usr/local/lib/ --with-curl=/usr/local/lib --with-apache=../apache_1.3.27 --enable-calendar --with-gettext=/bin --with-ming=/usr/lib --with-gd --enable-gd-native-ttf --with-png-dir=/usr --with-jpeg-dir=/usr --with-freetype-dir=/usr/local --with-bz2 --enable-debug=yes Apache - SSL_BASE="/usr/src/openssl-0.9.6b" ./configure --with-layout=RedHat --enable-module=so --enable-module=auth --enable-module=ssl --enable-module=proxy --activate-module=src/modules/php4/libphp4.a All things compiled successfully, but when I tried to run httpd with gdb, I get the following message: (gdb) run -X Starting program: /usr/sbin/httpd -X Program received signal SIGSEGV, Segmentation fault. 0x084c8100 in ?? () at eval.c:41 41 eval.c: No such file or directory. in eval.c When I compiled this without IMAP support, all works perfectly. php4-STABLE-200302071030 apache 1.3.27 imap-2001a-10 -- Edit bug report at http://bugs.php.net/?id=22106&edit=1 -- Try a CVS snapshot: http://bugs.php.net/fix.php?id=22106&r=trysnapshot Fixed in CVS: http://bugs.php.net/fix.php?id=22106&r=fixedcvs Fixed in release: http://bugs.php.net/fix.php?id=22106&r=alreadyfixed Need backtrace: http://bugs.php.net/fix.php?id=22106&r=needtrace Try newer version: http://bugs.php.net/fix.php?id=22106&r=oldversion Not developer issue:http://bugs.php.net/fix.php?id=22106&r=support Expected behavior: http://bugs.php.net/fix.php?id=22106&r=notwrong Not enough info:http://bugs.php.net/fix.php?id=22106&r=notenoughinfo Submitted twice:http://bugs.php.net/fix.php?id=22106&r=submittedtwice register_globals: http://bugs.php.net/fix.php?id=22106&r=globals PHP 3 support discontinued: http://bugs.php.net/fix.php?id=22106&r=php3 Daylight Savings: http://bugs.php.net/fix.php?id=22106&r=dst IIS Stability: http://bugs.php.net/fix.php?id=22106&r=isapi Install GNU Sed:http://bugs.php.net/fix.php?id=22106&r=gnused
#22086 [Opn->Bgs]: OCIBindByName causes problem if more than one Oracle statements are executed.
ID: 22086
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: OCI8 related
Operating System: Red Hat Linux 7.3
PHP Version: 5CVS-2003-02-06 (dev)
New Comment:
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php
You forgot to add the semicolon `;' at the end of the second statement.
Moreover - I doubt you can run this very thing he way you intended. Try
the PL/SQL in SQL *PLUS before trying to run it from PHP.
Conclusion - it is Oracle's error message due your bad PLSQL design.
Closed as Bogus
Previous Comments:
[2003-02-06 02:15:39] [EMAIL PROTECTED]
I have a script that combines various statements before it calls the
OCIParse or OCIExecute.
For instance
Begin
Insert into TABLEA(COLA, COLB, COLC) Values('VAL1', 'VAL2', 'VAL3');
Update TABLEB Set COLB = 'SOMEVAL' Where ROWID = :RID1
End;
when I call an OCIBindByName for :RID1 as
OCIBindByName($oci_stmt,":RID".$i,&$this->arr_rowid[$i],-1,OCI_B_ROWID);
where I've defined each subscript of arr_rowid using OCINewDescriptor
using the following
$this->arr_rowid[$i] =
OCINewDescriptor($this->obj_conn,OCI_D_ROWID);
OCIExecute gives me an error saying
Warning: OCIStmtExecute: ORA-06550: line 1, column 221: PL/SQL:
ORA-00933: SQL command not properly ended ORA-06550: line 1, column 93:
PL/SQL: SQL Statement ignored ORA-06550: line 1, column 224: PLS-00103:
Encountered the symbol "end-of-file" when expecting one of the
following: begin case declare end exception exit for goto if loop mod
null pragma raise return select update while with
/var/www/html/crp/includes/dbconn.inc on line 333
I'm still investigating into the issue. Instincts tell me that the
problem is due to multiple statements in 1 query so am all up on
changing the entire class for all such occurances. However, the attempt
to save database time by executing multiple queries together seems like
is not destined to work. If it doesn't work, I'll get back in here with
more info.
--
Edit this bug report at http://bugs.php.net/?id=22086&edit=1
#22026 [Opn->Bgs]: OCIBindByName trailing spaces
ID: 22026
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: OCI8 related
Operating System: Windows
PHP Version: 4.3.0
New Comment:
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. Because of this, we hope you add your comments
to the existing bug instead.
Thank you for your interest in PHP.
Indeed this is the duplicated report. Please follow up (as you have
also previousely done) on: http://bugs.php.net/14013
Secondly, this is an expected behavior, as Thies mentioned, Oracle
trims off the spaces. Not sure whether it is configurable somehow from
your side.
Maxim Maletsky
Previous Comments:
[2003-02-03 03:05:24] [EMAIL PROTECTED]
I guess I have a problem similar th ewone described in 14013.
When I use the OciBindByName, this function throw away the trailing
spaces which should be tranmitted via the bind variable. (When I'am
using the old Ora_Bind function it works like I expect).
For testing I minimized the problem to a "select from dual" to get it
as easy as possible.
I do four select-statement in each combination: the OCI- versus the old
Ora-functions and a bind-based versus a direct SQL-statement.
the php-code:
", OciResult($stm1, 1), "\n";
$stm2 = OciParse($conn, "select :input from dual");
OciBindByName($stm2, ":input", &$val, 10);
OciExecute($stm2);
OciFetch($stm2);
echo "", OciResult($stm2, 1), "\n";
OciLogoff($conn);
$Conn = Ora_Logon ("X@Z","Y");
$val = " X X ";
$Cursor = Ora_Open($Conn);
Ora_Parse($Cursor, "select '".$val."' from dual");
Ora_Exec($Cursor);
Ora_Fetch($Cursor);
echo "", Ora_getColumn($Cursor, 0), "\n";
Ora_Parse($Cursor, "select :input from dual");
Ora_Bind($Cursor, "val", ":input", 10);
Ora_Exec($Cursor);
Ora_Fetch($Cursor);
echo "", Ora_GetColumn($Cursor, 0), "\n";
Ora_Logoff($Conn);
?>
The output is:
X X
X X
X X
X X
And the second (5th) line (OCIBindByName) in the output is the one I
will not accept, because the tailing blank is away.
Best wishes,
Jens Reibiger
--
Edit this bug report at http://bugs.php.net/?id=22026&edit=1
#13907 [Opn]: Oracle Fetch row by row number
ID: 13907 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4.0.6 Assigned To: maxim New Comment: Just to follow up: Yes, to select the first 6 rows you can use subselects (besides there are other methods): SELECT * FROM (SELECT ename, hiredate FROM emp ORDER BY hiredate) WHERE ROWNUM < 6 Nevertheless, you still have selected the full stream in the subselected query *and* from the received result you've extracted the first 6 rows. What I am wondering here is, whether it could actually make any sense of having the offset functions that pretty much limit the Fetch loop inside OCI8 extension. Doesn't seem to me a clean method, but if this saves on speed and functionality/usability there is then a space for this function. Will look into it in details Previous Comments: [2003-01-30 06:23:40] [EMAIL PROTECTED] It is probably true. Will soon close it as bogus. I am still curious to see whether there is any "technical" way for it through OCI first. [2003-01-29 12:07:11] [EMAIL PROTECTED] Probably he/she doesn't really need a new function, but only a hint how to simulate the limit/offset syntax of MySQL/Postgresql. Without the help of <http://www.dclp-faq.de/q/q-oracle-limit.html> (in German, but not much text), I certainly would not know how to do it, although I asked our local SQL gurus. [2003-01-29 08:59:05] [EMAIL PROTECTED] Well, this wouldn't make much sence as this should be controlled by your SQL. What's the point to grab the whole table in your buffer to then fetch only a few rows somewhere in the middle? Anyhow, will assign it to myself for now. [2001-11-02 05:37:16] [EMAIL PROTECTED] Currently there's no way of fetching a row by row number. OCIFetchStatement() fetches all rows returned by a query. OCIFetchInto() only allows to return the NEXT row. It would make sense to be able to selectively fetch a subset of rows or single rows by row number for large row lists. -- Edit this bug report at http://bugs.php.net/?id=13907&edit=1
#13907 [Opn]: Oracle Fetch row by row number
ID: 13907 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4.0.6 Assigned To: maxim New Comment: It is probably true. Will soon close it as bogus. I am still curious to see whether there is any "technical" way for it through OCI first. Previous Comments: [2003-01-29 12:07:11] [EMAIL PROTECTED] Probably he/she doesn't really need a new function, but only a hint how to simulate the limit/offset syntax of MySQL/Postgresql. Without the help of <http://www.dclp-faq.de/q/q-oracle-limit.html> (in German, but not much text), I certainly would not know how to do it, although I asked our local SQL gurus. [2003-01-29 08:59:05] [EMAIL PROTECTED] Well, this wouldn't make much sence as this should be controlled by your SQL. What's the point to grab the whole table in your buffer to then fetch only a few rows somewhere in the middle? Anyhow, will assign it to myself for now. [2001-11-02 05:37:16] [EMAIL PROTECTED] Currently there's no way of fetching a row by row number. OCIFetchStatement() fetches all rows returned by a query. OCIFetchInto() only allows to return the NEXT row. It would make sense to be able to selectively fetch a subset of rows or single rows by row number for large row lists. -- Edit this bug report at http://bugs.php.net/?id=13907&edit=1
#15858 [Opn->Fbk]: Unable to load dynamic library liboci8.so
ID: 15858 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Feedback Bug Type: OCI8 related Operating System: UnixWare 7.1.1 PHP Version: 4.0.6-4.2.1 New Comment: Please try using this CVS snapshot: http://snaps.php.net/php4-STABLE-latest.tar.gz For Windows: http://snaps.php.net/win32/php4-win32-STABLE-latest.zip Previous Comments: [2002-10-17 07:59:02] [EMAIL PROTECTED] Still unable to compile, even with file.h fixed and with latest php snapshot. And I am sure I do not have two versions of Apache in my machine. Compilation error follows: gcc -I/usr/local/include -Isapi/apache/ -I/home/sw/php4-200210170300/sapi/apache/ -DPHP_ATOM_INC -I/home/sw/php4-200210170300/include -I/home/sw/php4-200210170300/main -I/home/sw/php4-200210170300 -I/home/sw/php4-200210170300/Zend -I/u01/app/oracle/product/8.1.7/rdbms/public -I/u01/app/oracle/product/8.1.7/rdbms/demo -I/home/sw/php4-200210170300/ext/xml/expat -DUW=700 -DMOD_SSL=208110 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/home/sw/php4-200210170300/TSRM -g -Wall -c /home/sw/php4-200210170300/sapi/apache/mod_php4.c -fPIC -DPIC -o sapi/apache/mod_php4.lo /home/sw/php4-200210170300/sapi/apache/mod_php4.c: In function `apache_php_module_shutdown_wrapper': /home/sw/php4-200210170300/sapi/apache/mod_php4.c:788: structure has no member named `shutdown' /home/sw/php4-200210170300/sapi/apache/mod_php4.c: In function `php_child_exit_handler': /home/sw/php4-200210170300/sapi/apache/mod_php4.c:809: structure has no member named `shutdown' make: *** [sapi/apache/mod_php4.lo] Error 1 [2002-10-07 18:46:21] [EMAIL PROTECTED] This really looks like something to be pretty broken in those header files. Try fixing this line: #define FDIRECT 0x20/* perform direct I/O/*/ to be: #define FDIRECT 0x20/* perform direct I/O */ (just remove that extra / in the comment) This might not fix the rest of the problems, but at least it gets rid of that one warning..which _might_ cause the other errors. And you don't have e.g. two versions of Apache in your machine, by any chance? [2002-10-07 03:51:57] [EMAIL PROTECTED] Lines 103-109 from file.h follow: #define FAPPEND 0x08 #define FSYNC 0x10 #define FDIRECT 0x20/* perform direct I/O/*/ #define FDSYNC 0x40/* perform data synchronous I/O */ #define FNONBLOCK 0x80 /* LFS SUPPORT */ #define FLARGEFILE 0x8 Full configure line used follows: ./configure --with-oci8=shared --with-apxs --without-mysql --enable-sigchild --build=i486-sco-sysv5uw7 --host=i486-sco-sysv5uw7 --enable-debug --disable-mbstring [2002-10-04 18:44:18] [EMAIL PROTECTED] Seems like something wrong in your header files. That warning about /usr/include/sys/file.h:105...what is in that file on that line? (and around it) Also, what was the full configure line used? [2002-10-04 08:26:52] [EMAIL PROTECTED] In newer snapshot this compile error persists, --disable-mbstring helps, but compilation then stops at gcc -I/usr/local/include -Isapi/apache/ -I/home/sw/php4-200210040300/sapi/apache/ -DPHP_ATOM_INC -I/home/sw/php4-200210040300/include -I/home/sw/php4-200210040300/main -I/home/sw/php4-200210040300 -I/home/sw/php4-200210040300/Zend -I/u01/app/oracle/product/8.1.7/rdbms/public -I/u01/app/oracle/product/8.1.7/rdbms/demo -I/home/sw/php4-200210040300/ext/xml/expat -DUW=700 -DMOD_SSL=208110 -DUSE_HSREGEX -DEAPI -DUSE_EXPAT -I/home/sw/php4-200210040300/TSRM -g -Wall -c /home/sw/php4-200210040300/sapi/apache/mod_php4.c -fPIC -DPIC -o sapi/apache/mod_php4.lo In file included from /usr/local/include/ap_config.h:1118, from /usr/local/include/httpd.h:72, from /home/sw/php4-200210040300/sapi/apache/php_apache_http.h:15, from /home/sw/php4-200210040300/sapi/apache/mod_php4.c:22: /usr/include/sys/file.h:105: warning: `/*' within comment /home/sw/php4-200210040300/sapi/apache/mod_php4.c: In function `apache_php_module_shutdown_wrapper': /home/sw/php4-200210040300/sapi/apache/mod_php4.c:788: structure has no member named `shutdown' /home/sw/php4-200210040300/sapi/apache/mod_php4.c: In function `php_child_exit_handler': /home/sw/php4-200210040300/sapi/apache/mod_php4.c:809: structure has no member named `shutdown' make: *** [sapi/apache/mod_php4.lo] Error 1 In the same configuration, version 4.2.3 can be compiled without any problem.
#2807 [Opn]: LOB descriptors with Fetch/Result and FetchInto
ID: 2807
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Solaris 2.6
PHP Version: 4.0
-Assigned To:
+Assigned To: maxim
New Comment:
well, since this is not assigned to anyone in the last two years, I
will mark it on myself as a reminder.
Previous Comments:
[2001-02-10 13:53:25] [EMAIL PROTECTED]
refiling against 4.0.
[1999-11-24 10:31:24] [EMAIL PROTECTED]
that's the way it's designed.
and i'm not sure if it can be changed - if you could provide me with
some docs how it's done i might have a look at it.
moving to Feature/Change request.
[1999-11-23 22:52:24] [EMAIL PROTECTED]
1. When selecting a row containing more than one LOB, the descriptors
for all but the
first LOB are freed after the fetches are complete.
2. When selecting multiple rows containing a LOB, descriptors are only
created for one
row and reused. Therefore, the descriptors are only valid for the last
row after the fetches
are complete. In addition, if each row contains more than one LOB, the
above condition also applies.
This becomes a problem when trying to create an array of the result set
for later user since all but one of
the LOB descriptors are no longer valid. LOB descriptors must be used
*immediately* when fetching
a row or they can't be used at all.
Unless using the OCI_RETURN_LOBS flag, LOB descriptors should be
created for
each row and shouldn't be freed until explicitly freed by the user. At
the very least,
a flag should be created that will allow this behavior
(OCI_RETURN_ALL_LOCATORS?).
Here are the details:
PHP 3.0.12
Apache 1.3.9.2
Oracle 8.0.4
Solaris 2.6
Fetch/Result
Code:
putenv("ORACLE_HOME=/oracle/home");
putenv("ORACLE_SID=sid");
OCIInternalDebug(1);
$conn = OCINLogon("test", "pass", "sid");
$sql = "SELECT id, clob, blob FROM foobar WHERE id IN (1, 2)";
$stmt = OCIParse($conn, $sql);
OCIExecute($stmt);
$rows = 0;
$cols = OCINumCols($stmt);
while (OCIFetch($stmt)) {
for ($i = 1; $i < $cols + 1; $i++) {
$colname = OCIColumnName($stmt, $i);
$select[$colname][$rows] = OCIResult($stmt, $i);
}
$rows++;
}
for ($i = 0; $i < $rows; $i++) {
echo "ID: ".$select["ID"][$i]."\n";
echo "Clob: ".$select["CLOB"][$i]->load()."\n"; // always
value for last row; only one descriptor created
echo "Blob: ".$select["BLOB"][$i]->load()."\n"; // fails;
descriptor already freed
}
OCIFreeStatement($stmt);
OCILogoff($conn);
Output (debug statements/warnings prefixed with *):
*OCIDebug: oci8_open_server new conn=2000 dname=sid
*OCIDebug: oci8_open_user new sess=1000 user=test
*OCIDebug: oci8_do_connect: id=1
*OCIDebug: oci8_parse "SELECT id, clob, blob FROM foobar WHERE id
IN (1, 2)" id=2 conn=1
*OCIDebug: OCIExecute: new descriptor for CLOB
*OCIDebug: OCIExecute: new descriptor for BLOB
*OCIDebug: oci8_free_descr: 3c5498
ID: 1
*OCIDebug: OCIloaddesc: size=14
Clob: blah blah blah
*Warning: unable to find my descriptor 1 in /.../test.phtml on
line xx
Blob:
ID: 2
*OCIDebug: OCIloaddesc: size=14
Clob: blah blah blah
*Warning: unable to find my descriptor 1 in /.../test.phtml on
line xx
Blob:
*OCIDebug: _oci8_free_stmt: id=2 last_query="SELECT id, clob, blob
FROM foobar WHERE id IN (1, 2)"
*OCIDebug: _oci8_close_conn: id=1
*OCIDebug: oci8_free_descr: 3c5508
FetchInto
Code:
putenv("ORACLE_HOME=/oracle/home");
putenv("ORACLE_SID=sid");
OCIInternalDebug(1);
$conn = OCINLogon("test", "pass", "sid");
$sql = "SELECT id, clob, blob FROM foobar WHERE id IN (1, 2)";
$stmt = OCIParse($conn, $sql);
OCIExecute($stmt);
$rows = 0;
while (OCIFetchInto($stmt, $select[$rows], OCI_ASSOC)) {
$rows++;
}
for ($i = 0; $i < $rows; $i++) {
echo "ID: ".$select[$i]["ID"]."\n";
echo "Clob: ".$select[$i]["CLOB"]->load()."\n"; // always
value for last row; only one descriptor created
echo "Blob: ".$select[$i]["BLOB"]->load()."\n"; // f
#8070 [Opn->Bgs]: wish list: oci8.max_persist in php.ini
ID: 8070 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: All PHP Version: 4.0.3pl1 New Comment: Please do not submit the same bug more than once. An existing bug report already describes this very problem. Even if you feel that your issue is somewhat different, the resolution is likely to be the same. Because of this, we hope you add your comments to the existing bug instead. Thank you for your interest in PHP. Later, there is #9517 which is the same. Will leave only that one. Previous Comments: [2000-12-01 14:50:25] [EMAIL PROTECTED] It'd be great to have a parameter for the maximum number of persistent database connections with oci8. Apologies if this already exits and just isn't documented. -- Edit this bug report at http://bugs.php.net/?id=8070&edit=1
#10350 [Opn]: OCIResult doesn't return time for an Oracle Date field
ID: 10350 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Sun OS 5.7 PHP Version: 4.0.3pl1 -Assigned To: +Assigned To: maxim New Comment: Besides being a little bit bogus, this also has chances to be already solved meanwhile. Previous Comments: [2001-04-16 17:49:58] [EMAIL PROTECTED] Seeing how it's a feature request, I guess it can't be Bogus or can it? -Chris [2001-04-16 17:48:13] [EMAIL PROTECTED] Joe Brown says: This is not a PHP bug. Consider setting NLS_DATE_FORMAT. The manual states OCIResult() returns everything as a string. NLS_DATE_FORMAT may not be appropriate for your needs. There are quite a few places you can set NLS_DATE_FORMAT. * Environment variables (or windows registry on win32) * orclSID.ora * on a per session basis; execute this statement after logon: $cursor=OCIParse($connection, "ALTER SESSION SET NLS_DATE_FORMAT='-MM-DD HH24:MI:SS'"); OCIExecute($cursor); OCIFreeCursor($cursor); [2001-04-16 16:07:54] [EMAIL PROTECTED] The Oracle Date fields are actually DateTime fields. Your OCIResult routinue returns the date only. As this point, you can't change what OCIResult does because you'd break existing code. I request that you add a new function allowing the recovery of the time value of an Orcale Date field. -- Edit this bug report at http://bugs.php.net/?id=10350&edit=1
#13906 [Opn]: Oracle OCI Non-Blocking mode
ID: 13906 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4.0.6 -Assigned To: +Assigned To: maxim New Comment: This one i already like better. Assigned. Previous Comments: [2001-11-02 05:21:24] [EMAIL PROTECTED] The Oracle OCI Module doesn't support non-blocking mode yet. This makes sense e.g. for cancelling SQL queries that run too long. This would include support for OCIBreak() and OCIReset() as well as get/set functions. -- Edit this bug report at http://bugs.php.net/?id=13906&edit=1
#13907 [Opn]: Oracle Fetch row by row number
ID: 13907 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: all PHP Version: 4.0.6 -Assigned To: +Assigned To: maxim New Comment: Well, this wouldn't make much sence as this should be controlled by your SQL. What's the point to grab the whole table in your buffer to then fetch only a few rows somewhere in the middle? Anyhow, will assign it to myself for now. Previous Comments: [2001-11-02 05:37:16] [EMAIL PROTECTED] Currently there's no way of fetching a row by row number. OCIFetchStatement() fetches all rows returned by a query. OCIFetchInto() only allows to return the NEXT row. It would make sense to be able to selectively fetch a subset of rows or single rows by row number for large row lists. -- Edit this bug report at http://bugs.php.net/?id=13907&edit=1
#19151 [Opn]: Checking for a valid PHP file from PHP
ID: 19151
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: Any
PHP Version: 4.2.2
New Comment:
I see no reasons why not to have it, especially if something like it
was already implemented... Anyone?
Previous Comments:
[2002-08-28 10:55:19] [EMAIL PROTECTED]
In the CLI version, you can do:
'php -l {filename}'
and find out whether the file you specified is syntactically correct.
This would be a powerful feature to be able to call from userland when
deciding whether or not to include files based on whether or not they
are valid PHP files.
I know this is in the Zend area of things, but it would be a very cool
addition.
In /sapi/cli/php_cli.c, it seems like a trivial function. Before
creating a function to submit, or someone beating me to it, is there a
good reason NOT to do this?
--
Edit this bug report at http://bugs.php.net/?id=19151&edit=1
#17063 [Opn]: Can't able to insert long datatype into oracle8 database
ID: 17063
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
-Bug Type: Oracle related
+Bug Type: OCI8 related
Operating System: Windows 2000
PHP Version: 4.1.2
New Comment:
Moving this to OCI8, which is where OCIPLogon() belongs.
(this mess between the two Oracle extensions gotta end someday
argh..)
Previous Comments:
[2002-05-07 04:38:05] [EMAIL PROTECTED]
Query toinsert user is - $q1";
$s1 = ociparse($c1, $q1);
ocibindbyname($s1, ":valdef", &$vals);
if($debug){$result = ociexecute($s1);} else {$result =
@ociexecute($s1);};
ocicommit($c1);
echo "The result from ins $result";
};
$col=('FILTER');
$val="('$str')";
gendbins1('adm','XMLLONG',$col,$val);
?>
here the code i am using and $str is in "TempStr.php" file and i am
able to inserting the small strings(Aprox 2k) and i could not able to
insert the big string. My table have only one column and datatype is
"long". My apache server and database are not in same mechine. This is
the information i am providing.
Bye
Suresh
[2002-05-07 03:05:07] [EMAIL PROTECTED]
Not enough information was provided for us to be able
to handle this bug. Please re-read the instructions at
http://bugs.php.net/how-to-report.php
If you can provide more information, feel free to add it
to this bug and change the status back to "Open".
[2002-05-07 00:38:26] [EMAIL PROTECTED]
Here small change i am not able to insert the long string i.e more than
50k but i can able in insert 1k string.
Thanks,
Suresh
[2002-05-07 00:28:31] [EMAIL PROTECTED]
Hi,
I am trying to insert the long datatype into oracle8 database but it is
throwing exception.
bye,
Suresh
--
Edit this bug report at http://bugs.php.net/?id=17063&edit=1
#17245 [Opn]: persistence connection problem(ociplogin)
ID: 17245 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open -Bug Type: Oracle related +Bug Type: OCI8 related Operating System: SUN os 5.6(Solaris) PHP Version: 4.1.2 New Comment: Moving this to OCI8, which is where OCIPLogin() belongs. Previous Comments: [2002-09-30 04:18:00] [EMAIL PROTECTED] Please tell me the solution of "Too many connection" the error occured in PHP while connecting to the database. if any body knows about the solution, then please mail me at the following email address: [EMAIL PROTECTED] I appreciate your help. Thanks [2002-05-15 07:32:10] [EMAIL PROTECTED] I am using apache1.3.22,php4.1.1 with oracle8 and OS is solaris as well as WINDOWS 2000. I am using the persistence connection(PHP ociplogin()) for update/insert/select to the database. The apache server is opeing a child process and holding connection(one connection per child) on every database transaction. For every request the connection is opening to database and it is not getting closed. As per PHP document(Pl refer the PHP doc on persistence connection) the child created by apache, holds the persistence connection until it die(child). But for every request the apache is crating the child(i am asuming... because it is opening databse connection every time) and it is trying to hold the database connection even the remaining childs are free(not doing any thing). After some time all of my database connections are in use and giving error "MAX number of connections exceeded". Bye SURESH. -- Edit this bug report at http://bugs.php.net/?id=17245&edit=1
#17015 [Opn->Bgs]: Ora_Error/Ora_ErrorCode
ID: 17015 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Oracle related Operating System: HP-Unix 11.X PHP Version: 4.1.2 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php Ora_do does not fail when there is no data returned, thus ora_error and/or ora_errorcode does not return any errors either. This is an expected behaviour. Previous Comments: [2002-05-05 10:41:56] [EMAIL PROTECTED] When checking for errors after Ora_Do, if the table is empty, neither of them (ora_error/ora_errorcode) return 1403 (no data found). Following is sample code: $query = "select * from test_table "; $qCursor = Ora_Do($oraConn, $query); $qError = Ora_ErrorCode($query); // $qError = Ora_Error($query); echo "Error = >".$qError."< \n"; -- Edit this bug report at http://bugs.php.net/?id=17015&edit=1
#21915 [Bgs]: ociBindByName doesn't work properly with char columns
ID: 21915 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: OCI8 related Operating System: Linux PHP Version: 4.2.3 New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is actually an expected behavior. Variable returned by bind from Oracle needs to fit into the POHP variable, thus you whether declare $text as 'texttextte'; (10 chars) or set it in OCIBindByName (10). Maxim Maletsky Previous Comments: [2003-01-28 05:41:37] [EMAIL PROTECTED] Thank you for taking the time to report a problem with PHP. Unfortunately you are not using a current version of PHP -- the problem might already be fixed. Please download a new PHP version from http://www.php.net/downloads.php If you are able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". Again, thank you for your continued support of PHP. PHP 4.3.0 [2003-01-28 02:42:01] [EMAIL PROTECTED] to make things clearer: c_column is a char(10) column, but there's also data stored that is shorter, e.g. 'text'. Therefore "Select * from t_table where c_column = 'text'" works. [2003-01-28 02:22:09] [EMAIL PROTECTED] when i select from a oracle8i: -- $stmt = ociparse($conn, "Select * from t_table where c_column = 'text'"); ociexecute($stmt); - and c_column is a char column, everything works fine, even if the data i'm asking for is shorter than the column. (c_column is a char(10) and i'm looking for 'text') but as soon as i use ocibindbyname, i won't get a result back: - $stmt = ociparse($conn, "Select * from t_table where c_column = :bindvar"); $text = 'text'; ocibindbyname($stmt, ":bindvar", &$text, -1); ociexecute($stmt); - it also doesn't work, if i set the length-parameter in ocibindbyname to the length of the char column or lenght+1: - $stmt = ociparse($conn, "Select * from t_table where c_column = :bindvar"); $text = 'text'; ocibindbyname($stmt, ":bindvar", &$text, 10); ociexecute($stmt); - ocibindbyname only works with char columns, when the data of the bindvariable is as long as the char column or if like-operator and % is used: - $stmt = ociparse($conn, "Select * from t_table where c_column like :bindvar"); $text = 'text%'; ocibindbyname($stmt, ":bindvar", &$text, -1); ociexecute($stmt); - -- Edit this bug report at http://bugs.php.net/?id=21915&edit=1
#21897 [Bgs]: ORA-03113: end-of-file on communication channel
ID: 21897 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: OCI8 related Operating System: Solaris PHP Version: 4.2.3 New Comment: This moves to bug #13053 Previous Comments: [2003-01-28 05:34:22] [EMAIL PROTECTED] Thanks. [2003-01-28 05:07:57] [EMAIL PROTECTED] ok. http://bugs.php.net/bug.php?id=13053&edit=1 seems to be the same problem. I close this bug and put my comments there. [2003-01-28 05:00:16] [EMAIL PROTECTED] Also this error occurs sometimes: Warning: OCISessionBegin: ORA-24327: need explicit attach before authenticating a user in /htdocs/e-academy.eui.at/www/oci8test.php on line 4 Error: 24327 Error: ORA-24327: need explicit attach before authenticating a user currently I'm sitting here at the customer and try to track down the problem. Any quick tips would be great. There are other webs running on this system using java without problems. Maybe there are problems running php + tomcat on the same apache at the same time?! [2003-01-27 14:49:15] [EMAIL PROTECTED] One more thing, the bug #1539 looks like a similar problem: http://bugs.php.net/bug.php?id=15390 If you consider it relevant, please comment under that bug instead of duplicating it at this point. Maxim Maletsky [2003-01-27 14:36:00] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Actually, I think Michael's is the most probable answer. Check out these places: http://dbforums.com/t584473.html http://dbforums.com/showthread.php?threadid=496655 http://home.clara.net/dwotton/dba/ora3113.htm http://www.google.com/search?q=Ora-03113+solaris&hl=en&lr=&ie=UTF-8&oe=utf-8&start=20&sa=N As you can see, this randomly hapens for various *nix installations and the most tipical case is the misconfiguration of the Oracle enviroment. As was also mentioned "Oracle's way to say you misconfigured him". Thus, I doubt this is really php's oci8 extension that causes it. Try also using SQL*Plus and see whether you get it. I'd be worried if this only happens connecting to Oracle thought PHP. If so, then please post us the full PHP code and/or anything you might have discovered. Maxim Maletsky 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/21897 -- Edit this bug report at http://bugs.php.net/?id=21897&edit=1
#13053 [Bgs]: oci8 error, this kill oracle-prosseces in the oracle-instance.
ID: 13053 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: OCI8 related Operating System: sun solaris 64 bits PHP Version: 4.0.6 New Comment: Note: Bug #21897 ORA-03113: end-of-file on communication channel is relevant, but close because duplicated. This one seems to be "bogus", though i hpe to see whether the bug can still be encountered and have some more details to trace it down. Maxim Maletsky Previous Comments: [2002-12-02 09:48:10] [EMAIL PROTECTED] Hi, The last news about our ORA-24327 error We changed the version of php into 4.2.3 and it seems that the connection failed problem has disappeared. Thanx for your advice, Caroline :o) [2002-11-26 10:37:00] [EMAIL PROTECTED] Yes. Try the lastest CVS from snaps.php.net and, if this still happens, give us some more details. [2002-11-26 04:22:55] [EMAIL PROTECTED] I have exactly the same problem with PHP 4.1.1 Do I need to change the php version to solve this bug ? [2002-04-13 08:51:25] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2001-08-30 05:34:29] [EMAIL PROTECTED] Oci statement faild: My error is: Warning: OCISessionBegin: ORA-24327: need explicit attach before authenticating a user and Supplied argument is not a valid OCI8-Connection resource and some rollback error as well. regards Jan Arve -- Edit this bug report at http://bugs.php.net/?id=13053&edit=1
#17381 [Opn]: OCI fetch routines not working with UTF8 DB
ID: 17381 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: OCI8 related Operating System: Win NT PHP Version: 4.2.1 Assigned To: maxim New Comment: Any updates on this? Has anyone tried this behaviour on PHP 4.3.0 or the latest CVS? There were some fixes in mbstring as well as CVS now has an improved NLS_LANG behavior for Oracle 9. I wonder if this problem still persists for you. Maxim Maletsky Previous Comments: [2002-11-22 07:58:44] [EMAIL PROTECTED] Can you try the latests CVS snapshot? There have been lots of fixes in mbstring. It might depend on it. [2002-11-18 11:21:02] [EMAIL PROTECTED] I'm having exactly the same problem here. PHP 4.2.2 RH Linux 2.4.9-34smp #1 SMP i686 Apache/1.3.22 Oracle 8i database with UTF8 characterset. Heelp? [2002-09-27 10:55:29] [EMAIL PROTECTED] I am experiencing the same problem. PHP 4.2.2 Red Hat Linux 7.2 Apache 1.3.26 Unable to insert multi-byte strings into Oracle and select it back out. Using mbstring and oci8 functions. Any progress on this one? [2002-07-23 05:09:59] [EMAIL PROTECTED] I met this kind of problems too. my database's character set is zhs16cgb231280, zhs16gbk, can not work too. the output i got is "aabb" which should be "aabb" (X present a 2-byte-chinese char) i set the NLS_LANG use SetEnv in httpd.conf of apache, the NLS_LANG changed but he result is unchanged. someone suggested that use "export NLS_LANG=" in apachectl script file, i tried, but failed. all "" except use charset us7ascii failed with an oracle error ora-12705, "unacceptable char set". [2002-05-23 06:50:05] [EMAIL PROTECTED] Can I just point out that I have used putenv, to set NLS_LANG in the example, because I thought that the system-wide environment variable $NLS_LANG was not being picked up. It is currently set to "American_America.UTF8". 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/17381 -- Edit this bug report at http://bugs.php.net/?id=17381&edit=1
#21897 [Bgs]: ORA-03113: end-of-file on communication channel
ID: 21897 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: OCI8 related Operating System: Solaris PHP Version: 4.2.3 New Comment: One more thing, the bug #1539 looks like a similar problem: http://bugs.php.net/bug.php?id=15390 If you consider it relevant, please comment under that bug instead of duplicating it at this point. Maxim Maletsky Previous Comments: [2003-01-27 14:36:00] [EMAIL PROTECTED] Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Actually, I think Michael's is the most probable answer. Check out these places: http://dbforums.com/t584473.html http://dbforums.com/showthread.php?threadid=496655 http://home.clara.net/dwotton/dba/ora3113.htm http://www.google.com/search?q=Ora-03113+solaris&hl=en&lr=&ie=UTF-8&oe=utf-8&start=20&sa=N As you can see, this randomly hapens for various *nix installations and the most tipical case is the misconfiguration of the Oracle enviroment. As was also mentioned "Oracle's way to say you misconfigured him". Thus, I doubt this is really php's oci8 extension that causes it. Try also using SQL*Plus and see whether you get it. I'd be worried if this only happens connecting to Oracle thought PHP. If so, then please post us the full PHP code and/or anything you might have discovered. Maxim Maletsky [2003-01-27 12:37:40] [EMAIL PROTECTED] Make sure you set the environment variables mentioned on <http://de3.php.net/manual/de/ref.oci8.php> before you start your httpd. _Don't_ set them in PHP with putenv() or in httpd.conf with SetEnv. If this doesn't help, maybe you can find the cause of the problem by reading <http://www.oracle-error.com/ora-03113.htm>. [2003-01-27 04:24:39] [EMAIL PROTECTED] This error occurs very often but not allways: FEHLER: Database error: ALTER SESSION SET NLS_DATE_FORMAT="-MM-DD HH24:MI:SS" Oracle8 Error: O (ORA-03113: end-of-file on communication channel ) Session halted. Warning: failed to rollback outstanding transactions!: ORA-03114: not connected to ORACLE in Unknown on line 0 it seems that the Oracle connection died, but the oci8 extension doesen't know this. The sql-statement above is the first after OCIPlogon(), changing to OCINLogon() doesen't solved this problem. We run the same application on other platforms with Oracle without any problems, this problem seems to be Solaris related. The Oracle Version is 8.1.7.4. Apache 1.3.26. The problem also occurs with PHP4.1.1 -- Edit this bug report at http://bugs.php.net/?id=21897&edit=1
#21897 [Opn->Bgs]: ORA-03113: end-of-file on communication channel
ID: 21897 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: Solaris PHP Version: 4.2.3 New Comment: Sorry, but your problem does not imply a bug in PHP itself. For a list of more appropriate places to ask for help using PHP, please visit http://www.php.net/support.php as this bug system is not the appropriate forum for asking support questions. Thank you for your interest in PHP. Actually, I think Michael's is the most probable answer. Check out these places: http://dbforums.com/t584473.html http://dbforums.com/showthread.php?threadid=496655 http://home.clara.net/dwotton/dba/ora3113.htm http://www.google.com/search?q=Ora-03113+solaris&hl=en&lr=&ie=UTF-8&oe=utf-8&start=20&sa=N As you can see, this randomly hapens for various *nix installations and the most tipical case is the misconfiguration of the Oracle enviroment. As was also mentioned "Oracle's way to say you misconfigured him". Thus, I doubt this is really php's oci8 extension that causes it. Try also using SQL*Plus and see whether you get it. I'd be worried if this only happens connecting to Oracle thought PHP. If so, then please post us the full PHP code and/or anything you might have discovered. Maxim Maletsky Previous Comments: [2003-01-27 12:37:40] [EMAIL PROTECTED] Make sure you set the environment variables mentioned on <http://de3.php.net/manual/de/ref.oci8.php> before you start your httpd. _Don't_ set them in PHP with putenv() or in httpd.conf with SetEnv. If this doesn't help, maybe you can find the cause of the problem by reading <http://www.oracle-error.com/ora-03113.htm>. [2003-01-27 04:24:39] [EMAIL PROTECTED] This error occurs very often but not allways: FEHLER: Database error: ALTER SESSION SET NLS_DATE_FORMAT="-MM-DD HH24:MI:SS" Oracle8 Error: O (ORA-03113: end-of-file on communication channel ) Session halted. Warning: failed to rollback outstanding transactions!: ORA-03114: not connected to ORACLE in Unknown on line 0 it seems that the Oracle connection died, but the oci8 extension doesen't know this. The sql-statement above is the first after OCIPlogon(), changing to OCINLogon() doesen't solved this problem. We run the same application on other platforms with Oracle without any problems, this problem seems to be Solaris related. The Oracle Version is 8.1.7.4. Apache 1.3.26. The problem also occurs with PHP4.1.1 -- Edit this bug report at http://bugs.php.net/?id=21897&edit=1
#17448 [Fbk->Csd]: if return value of oci function is OCI_SUCCESS_WITH_INFO, php assumes it error.
ID: 17448
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Feedback
+Status: Closed
Bug Type: OCI8 related
Operating System: linux
PHP Version: 4.2.1
Assigned To: scohen
New Comment:
This bug has been fixed in CVS.
In case this was a PHP problem, 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/.
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
Thank you for the report, and for helping us make PHP better.
I've set OCI_SUCCESS_WITH_INFO to also print out the message within the
default empty warning. This should not break any BC and will only
visualize what the *_INFO is.
Maxim Maletsky
Previous Comments:
[2003-01-27 11:59:54] [EMAIL PROTECTED]
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Question,
Where have you seen the error "password Will Be Expired" ? The only
message known to me is:
ORA-28002: the password will expire within num days
(http://storacle.princeton.edu:9001/oracle8-doc/server.805/a58312/newch296.htm#35114)
Which is quite logical, you get a warning when it expired. Is it
exactly the message you have seen?
To continue on this bug I need:
1. Confirm the error number for the "pawword Will Be Expired" error you
refered to
2. Ways (steps) to reduplicate this behaviour.
Thanks,
Maxim Maletsky
[2002-11-22 08:10:52] [EMAIL PROTECTED]
Any work/research on this one?
[2002-06-20 14:41:11] [EMAIL PROTECTED]
Reclassified.
[2002-05-27 03:46:32] [EMAIL PROTECTED]
If return value of OCI function is OCI_SUCCESS_WITH_INFO, php assumes
it error. and it don't generate message about INFO. so user cannot know
what problem is.
Using php and oracle, I found OCI_SUCESS_WITH_INFO, but cannot known
what problem is. for a long time I try to know it, finally I know. It
is "password will be expired" ¤Ñ.¤Ñ;
When return value of OCI function is OCI_SUCESS_WITH_INFO,
we get specific message using OCIErrGet() function like OCI_ERROR.
so, I hope to fix that OCI_SUCCESS_WITH_INFO of following function
equals OCI_ERROR of it.
(ext/oci8/oci8.c)
static ub4
oci_error(OCIError *err_p, char *what, sword status)
{
text errbuf[512];
sb4 errcode = 0;
switch (status) {
case OCI_SUCCESS:
break;
case OCI_SUCCESS_WITH_INFO:
php_error(E_WARNING, "%s: OCI_SUCCESS_WITH_INFO",
what);
break;
case OCI_NEED_DATA:
php_error(E_WARNING, "%s: OCI_NEED_DATA", what);
break;
case OCI_NO_DATA:
php_error(E_WARNING, "%s: OCI_NO_DATA", what);
break;
case OCI_ERROR: {
TSRMLS_FETCH();
CALL_OCI(OCIErrorGet(
err_p,
(ub4)1,
NULL,
&errcode,
errbuf,
(ub4)sizeof(errbuf),
(ub4)OCI_HTYPE_ERROR));
php_error(E_WARNING, "%s: %s", what, errbuf);
break;
}
case OCI_INVALID_HANDLE:
php_error(E_WARNING, "%s: OCI_INVALID_HANDLE", what);
break;
case OCI_STILL_EXECUTING:
php_error(E_WARNING, "%s: OCI_STILL_EXECUTING", what);
break;
case OCI_CONTINUE:
php_error(E_WARNING, "%s: OCI_CONTINUE", what);
break;
default:
break;
}
return errcode;
}
--
Edit this bug report at http://bugs.php.net/?id=17448&edit=1
#17448 [Opn->Fbk]: if return value of oci function is OCI_SUCCESS_WITH_INFO, php assumes it error.
ID: 17448
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Feedback
Bug Type: OCI8 related
Operating System: linux
PHP Version: 4.2.1
Assigned To: scohen
New Comment:
Thank you for this bug report. To properly diagnose the problem, we
need a backtrace to see what is happening behind the scenes. To
find out how to generate a backtrace, please read
http://bugs.php.net/bugs-generating-backtrace.php
Once you have generated a backtrace, please submit it to this bug
report and change the status back to "Open". Thank you for helping
us make PHP better.
Question,
Where have you seen the error "password Will Be Expired" ? The only
message known to me is:
ORA-28002: the password will expire within num days
(http://storacle.princeton.edu:9001/oracle8-doc/server.805/a58312/newch296.htm#35114)
Which is quite logical, you get a warning when it expired. Is it
exactly the message you have seen?
To continue on this bug I need:
1. Confirm the error number for the "pawword Will Be Expired" error you
refered to
2. Ways (steps) to reduplicate this behaviour.
Thanks,
Maxim Maletsky
Previous Comments:
[2002-11-22 08:10:52] [EMAIL PROTECTED]
Any work/research on this one?
[2002-06-20 14:41:11] [EMAIL PROTECTED]
Reclassified.
[2002-05-27 03:46:32] [EMAIL PROTECTED]
If return value of OCI function is OCI_SUCCESS_WITH_INFO, php assumes
it error. and it don't generate message about INFO. so user cannot know
what problem is.
Using php and oracle, I found OCI_SUCESS_WITH_INFO, but cannot known
what problem is. for a long time I try to know it, finally I know. It
is "password will be expired" ¤Ñ.¤Ñ;
When return value of OCI function is OCI_SUCESS_WITH_INFO,
we get specific message using OCIErrGet() function like OCI_ERROR.
so, I hope to fix that OCI_SUCCESS_WITH_INFO of following function
equals OCI_ERROR of it.
(ext/oci8/oci8.c)
static ub4
oci_error(OCIError *err_p, char *what, sword status)
{
text errbuf[512];
sb4 errcode = 0;
switch (status) {
case OCI_SUCCESS:
break;
case OCI_SUCCESS_WITH_INFO:
php_error(E_WARNING, "%s: OCI_SUCCESS_WITH_INFO",
what);
break;
case OCI_NEED_DATA:
php_error(E_WARNING, "%s: OCI_NEED_DATA", what);
break;
case OCI_NO_DATA:
php_error(E_WARNING, "%s: OCI_NO_DATA", what);
break;
case OCI_ERROR: {
TSRMLS_FETCH();
CALL_OCI(OCIErrorGet(
err_p,
(ub4)1,
NULL,
&errcode,
errbuf,
(ub4)sizeof(errbuf),
(ub4)OCI_HTYPE_ERROR));
php_error(E_WARNING, "%s: %s", what, errbuf);
break;
}
case OCI_INVALID_HANDLE:
php_error(E_WARNING, "%s: OCI_INVALID_HANDLE", what);
break;
case OCI_STILL_EXECUTING:
php_error(E_WARNING, "%s: OCI_STILL_EXECUTING", what);
break;
case OCI_CONTINUE:
php_error(E_WARNING, "%s: OCI_CONTINUE", what);
break;
default:
break;
}
return errcode;
}
--
Edit this bug report at http://bugs.php.net/?id=17448&edit=1
#21215 [Opn->Csd]: OCI8 calls not taking advantage of SHARED_MODE
ID: 21215 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: OCI8 related Operating System: Linux 2.4 PHP Version: 4.2.3 New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. >From what I see in CVS ldixon has already fixed this one himself. Will mark it as closed. Previous Comments: [2002-12-27 11:23:15] [EMAIL PROTECTED] OCIServerAttach() is used, implying that the module should take advantage of shared data mode, but OCIInitilize() was not passed SHARED_MODE flag (#define PHP_OCI_INIT_MODE OCI_DEFAULT), so I don't believe it's really taking advantage of shared data mode. Excerpt from OCI8 docs: To trigger OCI shared mode functionality, process handle parameters must be set and OCIInitialize() must be called with the mode flag set to OCI_SHARED. For example: ub4 mode = OCI_SHARED | OCI_THREADED; OCIInitialize (mode, 0, 0, 0, 0); The first application that initializes OCI in shared mode starts up the shared subsystem using the parameters set by that OCI application. When subsequent applications initialize using the shared mode, they use the previously started shared subsystem. Using this should reduce memory usage when large number of simultaneous connections are open and large numbers of concurrent statements (differing only by bind values) are running. ref: http://www.csee.umbc.edu/help/oracle8/server.815/a67846/basics.htm#425685 -- Edit this bug report at http://bugs.php.net/?id=21215&edit=1
#18621 [Opn->Bgs]: Can't lock row in oracle8i
ID: 18621
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Bogus
Bug Type: OCI8 related
Operating System: windows2000
PHP Version: 4.2.1
New Comment:
Sorry, but your problem does not imply a bug in PHP itself. For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.
Thank you for your interest in PHP.
Previous Comments:
[2002-07-29 09:10:34] [EMAIL PROTECTED]
I would like to lock row for update but it can't lock .If I lock row in
sql*plus by sql command "select * from table where ... for update
nowait" it can check lock and display massage 'read only'. How can I
do?
my code:
...
$gcom ='select * from admin.USERS where ACCOUNT = '."'".$ACCOUNT."'
for update nowait";
$result = OCIParse($conn, $gcom);
$chk = OCIExecute($result,OCI_DEFAULT);
if(!$chk){
$gcom ='select * from admin.USERS where ACCOUNT =
'."'".$ACCOUNT."'";
$mess = "Read only";
$result = OCIParse($conn, $gcom);
$chk = OCIExecute($result,OCI_DEFAULT);
}else {$mess="Read/Write";}
echo $mess;
$rows = OCIFetchStatement($result,$results);
...
--
Edit this bug report at http://bugs.php.net/?id=18621&edit=1
#19517 [Opn]: the oci8 function cause apache to crash
ID: 19517 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: OCI8 related Operating System: windows 2000 and linux PHP Version: 4.2.3 New Comment: This might be an Apache 2 problem. Can you reproduce the crash with the latest CVS release on Apache over 2.0.43? Previous Comments: [2002-11-05 14:13:23] [EMAIL PROTECTED] I get this error in my apache error log when multithreading is turned on: [notice] child pid 28373 exit signal Segmentation fault (11) Apache: 2.0.X (mpm worker) OS: HP-UX 11.00 (with linker patches) PHP: 4.2.2 dso with oci8 extension Oracle: 8.1.6 If I set ThreadsPerChild to 1 (single threaded), I don't get any segfaults. With ThreadsPerChild set to 2 (or higher) I get the segmentation faults with as few as 2 concurrent requests (ab -n 10 -c 2 http://testurl/). With particularly high load (>100 concurrent requests) Apache 2 hangs, and has to be killed. I also get this error message in my php log: "PHP Warning: _oci_open_server: ORA-12154: TNS:could not resolve service name" On the same system, Apache 1.3.26 with PHP as CGI works perfectly. [2002-09-20 03:30:06] [EMAIL PROTECTED] on medium/high load and on multi-threaded serveurs ( apache 1.3.X windows and apache 2.0.X (mpm=worker) on linux), oci cause segmentation fault to apache. I test with apache 1.3.26 / 2.0.40 on windows 2000 server and professionnal, php 4.2.3, oracle 8.1.7.0 and 9.0.1 ( on the same and different Pc). I test with and without autocommit. i always get the same result. the script: i run test with microsoft web apllication stress tools and ab. the error message is : _oci_open_server: ORA12154 TNS: could not resolve service name. All works fine with linux / apache 1.3.X. -- Edit this bug report at http://bugs.php.net/?id=19517&edit=1
#19735 [Opn->Ver]: Oracle - kgepop error OciNewCollection
ID: 19735
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Verified
Bug Type: OCI8 related
Operating System: NT4 SP3
PHP Version: 4.2.1
New Comment:
Just reproduced the crash.
On web server these two lines completely crash the whole thing. Most
importantly, I wasn't even able to trace it.
m
Previous Comments:
[2002-10-03 09:33:12] [EMAIL PROTECTED]
When run from command line:
$Conn = OciLogon("user", "pass", "db") or die("error");
$Coll = OciNewCollection($Conn, "valid_type_or_nonsense");
consistently causes following error:
kgepop: no error frame to pop to for error 21522
Don't know if same error occurs on web server (don't use version with
collection capabilities on server)
php.exe straight from win32 zip.
php_oc8.dll extension enabled.
--
Edit this bug report at http://bugs.php.net/?id=19735&edit=1
#13053 [Bgs]: oci8 error, this kill oracle-prosseces in the oracle-instance.
ID: 13053 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Bogus Bug Type: OCI8 related Operating System: sun solaris 64 bits PHP Version: 4.0.6 New Comment: Yes. Try the lastest CVS from snaps.php.net and, if this still happens, give us some more details. Previous Comments: [2002-11-26 04:22:55] [EMAIL PROTECTED] I have exactly the same problem with PHP 4.1.1 Do I need to change the php version to solve this bug ? [2002-04-13 08:51:25] [EMAIL PROTECTED] The version of PHP that this bug was reported in is too old. Please try to reproduce this bug in the latest version of PHP (available from http://www.php.net/downloads.php If you are still able to reproduce the bug with one of the latest versions of PHP, please change the PHP version on this bug report to the version you tested and change the status back to "Open". [2001-08-30 05:34:29] [EMAIL PROTECTED] Oci statement faild: My error is: Warning: OCISessionBegin: ORA-24327: need explicit attach before authenticating a user and Supplied argument is not a valid OCI8-Connection resource and some rollback error as well. regards Jan Arve -- Edit this bug report at http://bugs.php.net/?id=13053&edit=1
#16798 [Opn->Csd]: Compile failure:`OCI_DURATION_STATEMENT' undeclared (first use in this function)
ID: 16798 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Closed Bug Type: OCI8 related Operating System: Linux PHP Version: 4.2.0 Assigned To: maxim New Comment: This bug has been fixed in CVS. In case this was a PHP problem, 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/. In case this was a documentation problem, the fix will show up soon at http://www.php.net/manual/. In case this was a PHP.net website problem, the change will show up on the PHP.net site and on the mirror sites in short time. Thank you for the report, and for helping us make PHP better. Previous Comments: [2002-11-25 10:34:38] [EMAIL PROTECTED] What exactly is the minor version of your Oracle 8? It seems that `OCI_DURATION_STATEMENT' doesn't work on Oracle < 8.1 if used for creating TMP Lobs: http://lbdwww.epfl.ch/f/teaching/courses/oracle9i/appdev.920/a96584/oci16m10.htm#546355 Please confirm me the exact version details. Maxim Maletsky [2002-04-26 15:23:50] [EMAIL PROTECTED] . [2002-04-26 15:12:57] [EMAIL PROTECTED] make[3]: Entering directory `/usr/src/php-4.2.0/ext/oci8' gcc -I. -I/usr/src/php-4.2.0/ext/oci8 -I/usr/src/php-4.2.0/main -I/usr/src/php-4 .2.0 -I/usr/src/apache_1.3.22/src/include -I/usr/src/apache_1.3.22/src/os/unix - I/usr/src/php-4.2.0/Zend -I/usr/src/php-4.2.0/ext/mysql/libmysql -I/home/oracle/ product/1.0/rdbms/demo -I/usr/src/php-4.2.0/ext/xml/expat -I/usr/src/php-4.2.0/ TSRM -g -O2 -c oci8.c && touch oci8.lo oci8.c: In function `zif_ociwritetemporarylob': oci8.c:3383: `OCI_DURATION_STATEMENT' undeclared (first use in this function) oci8.c:3383: (Each undeclared identifier is reported only once oci8.c:3383: for each function it appears in.) make[3]: *** [oci8.lo] Error 1 make[3]: Leaving directory `/usr/src/php-4.2.0/ext/oci8' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/php-4.2.0/ext/oci8' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/php-4.2.0/ext' make: *** [all-recursive] Error 1 [2002-04-26 11:56:50] [EMAIL PROTECTED] What's your configure line? In which file and function do you get this error? [2002-04-24 19:56:06] [EMAIL PROTECTED] reclassified. 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/16798 -- Edit this bug report at http://bugs.php.net/?id=16798&edit=1
#16798 [Opn]: Compile failure:`OCI_DURATION_STATEMENT' undeclared (first use in this function)
ID: 16798 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: OCI8 related Operating System: Linux PHP Version: 4.2.0 -Assigned To: +Assigned To: maxim New Comment: What exactly is the minor version of your Oracle 8? It seems that `OCI_DURATION_STATEMENT' doesn't work on Oracle < 8.1 if used for creating TMP Lobs: http://lbdwww.epfl.ch/f/teaching/courses/oracle9i/appdev.920/a96584/oci16m10.htm#546355 Please confirm me the exact version details. Maxim Maletsky Previous Comments: [2002-04-26 15:23:50] [EMAIL PROTECTED] . [2002-04-26 15:12:57] [EMAIL PROTECTED] make[3]: Entering directory `/usr/src/php-4.2.0/ext/oci8' gcc -I. -I/usr/src/php-4.2.0/ext/oci8 -I/usr/src/php-4.2.0/main -I/usr/src/php-4 .2.0 -I/usr/src/apache_1.3.22/src/include -I/usr/src/apache_1.3.22/src/os/unix - I/usr/src/php-4.2.0/Zend -I/usr/src/php-4.2.0/ext/mysql/libmysql -I/home/oracle/ product/1.0/rdbms/demo -I/usr/src/php-4.2.0/ext/xml/expat -I/usr/src/php-4.2.0/ TSRM -g -O2 -c oci8.c && touch oci8.lo oci8.c: In function `zif_ociwritetemporarylob': oci8.c:3383: `OCI_DURATION_STATEMENT' undeclared (first use in this function) oci8.c:3383: (Each undeclared identifier is reported only once oci8.c:3383: for each function it appears in.) make[3]: *** [oci8.lo] Error 1 make[3]: Leaving directory `/usr/src/php-4.2.0/ext/oci8' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/src/php-4.2.0/ext/oci8' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/src/php-4.2.0/ext' make: *** [all-recursive] Error 1 [2002-04-26 11:56:50] [EMAIL PROTECTED] What's your configure line? In which file and function do you get this error? [2002-04-24 19:56:06] [EMAIL PROTECTED] reclassified. [2002-04-24 12:01:36] [EMAIL PROTECTED] I can´t compile PHP-4.2.0 with oracle 8. `OCI_DURATION_STATEMENT' undeclared (first use in this function) -- Edit this bug report at http://bugs.php.net/?id=16798&edit=1
#17448 [Opn]: if return value of oci function is OCI_SUCCESS_WITH_INFO, php assumes it error.
ID: 17448
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: OCI8 related
Operating System: linux
PHP Version: 4.2.1
Assigned To: scohen
New Comment:
Any work/research on this one?
Previous Comments:
[2002-06-20 14:41:11] [EMAIL PROTECTED]
Reclassified.
[2002-05-27 03:46:32] [EMAIL PROTECTED]
If return value of OCI function is OCI_SUCCESS_WITH_INFO, php assumes
it error. and it don't generate message about INFO. so user cannot know
what problem is.
Using php and oracle, I found OCI_SUCESS_WITH_INFO, but cannot known
what problem is. for a long time I try to know it, finally I know. It
is "password will be expired" ¤Ñ.¤Ñ;
When return value of OCI function is OCI_SUCESS_WITH_INFO,
we get specific message using OCIErrGet() function like OCI_ERROR.
so, I hope to fix that OCI_SUCCESS_WITH_INFO of following function
equals OCI_ERROR of it.
(ext/oci8/oci8.c)
static ub4
oci_error(OCIError *err_p, char *what, sword status)
{
text errbuf[512];
sb4 errcode = 0;
switch (status) {
case OCI_SUCCESS:
break;
case OCI_SUCCESS_WITH_INFO:
php_error(E_WARNING, "%s: OCI_SUCCESS_WITH_INFO",
what);
break;
case OCI_NEED_DATA:
php_error(E_WARNING, "%s: OCI_NEED_DATA", what);
break;
case OCI_NO_DATA:
php_error(E_WARNING, "%s: OCI_NO_DATA", what);
break;
case OCI_ERROR: {
TSRMLS_FETCH();
CALL_OCI(OCIErrorGet(
err_p,
(ub4)1,
NULL,
&errcode,
errbuf,
(ub4)sizeof(errbuf),
(ub4)OCI_HTYPE_ERROR));
php_error(E_WARNING, "%s: %s", what, errbuf);
break;
}
case OCI_INVALID_HANDLE:
php_error(E_WARNING, "%s: OCI_INVALID_HANDLE", what);
break;
case OCI_STILL_EXECUTING:
php_error(E_WARNING, "%s: OCI_STILL_EXECUTING", what);
break;
case OCI_CONTINUE:
php_error(E_WARNING, "%s: OCI_CONTINUE", what);
break;
default:
break;
}
return errcode;
}
--
Edit this bug report at http://bugs.php.net/?id=17448&edit=1
#17381 [Opn]: OCI fetch routines not working with UTF8 DB
ID: 17381 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: OCI8 related Operating System: Win NT PHP Version: 4.2.1 -Assigned To: +Assigned To: maxim New Comment: Can you try the latests CVS snapshot? There have been lots of fixes in mbstring. It might depend on it. Previous Comments: [2002-11-18 11:21:02] [EMAIL PROTECTED] I'm having exactly the same problem here. PHP 4.2.2 RH Linux 2.4.9-34smp #1 SMP i686 Apache/1.3.22 Oracle 8i database with UTF8 characterset. Heelp? [2002-09-27 10:55:29] [EMAIL PROTECTED] I am experiencing the same problem. PHP 4.2.2 Red Hat Linux 7.2 Apache 1.3.26 Unable to insert multi-byte strings into Oracle and select it back out. Using mbstring and oci8 functions. Any progress on this one? [2002-07-23 05:09:59] [EMAIL PROTECTED] I met this kind of problems too. my database's character set is zhs16cgb231280, zhs16gbk, can not work too. the output i got is "aabb" which should be "aabb" (X present a 2-byte-chinese char) i set the NLS_LANG use SetEnv in httpd.conf of apache, the NLS_LANG changed but he result is unchanged. someone suggested that use "export NLS_LANG=" in apachectl script file, i tried, but failed. all "" except use charset us7ascii failed with an oracle error ora-12705, "unacceptable char set". [2002-05-23 06:50:05] [EMAIL PROTECTED] Can I just point out that I have used putenv, to set NLS_LANG in the example, because I thought that the system-wide environment variable $NLS_LANG was not being picked up. It is currently set to "American_America.UTF8". [2002-05-23 05:34:35] [EMAIL PROTECTED] Email typo in original post.. :-) 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/17381 -- Edit this bug report at http://bugs.php.net/?id=17381&edit=1
#19687 [Asn]: ociexecute calling procedure with boolean out parameter
ID: 19687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Assigned -Bug Type: OCI8 related +Bug Type: Feature/Change Request Operating System: win 2k PHP Version: 4.2.1 Assigned To: maxim New Comment: An update: Oracle Call Interface specs say there are a few types that cannot be returned to client from DB. These are BOOLEAN, RECORD and INDEX TABLE. So, for BOOLEAN to work with OCI8 extebsion there must be a wrapper added in some way that, still in PLSQL encodes/decodes BOOLEAN to/from NUMBER that can be returned to OCI8 extension and then used by PHP as PHP's BOOLEAN type. In other words - this issue is not really any kind of bug but rather an expected behavior. Yet, I'd love to get it working somehow. I reclassify it to the feature request and will work on it some time later. Thanks, Maxim Maletsky Previous Comments: [2002-11-10 14:52:35] [EMAIL PROTECTED] I was planning to take over this one ... [2002-11-10 00:18:56] [EMAIL PROTECTED] It is actually not a bug but rather the limitation of binding variables. We hope to add it some time soon. Maxim Maletsky [2002-10-01 06:54:18] [EMAIL PROTECTED] PROBLEM OCIEXECUTE WITH BOOLEAN OUTPUT PARAMETERS: The call to the following stored procedure (oracle 8.1.7) from php4.2.1 (as ampache module) does not work with a boolean parameter. It works fine however when I change boolean to NUMBER. / the procedure in PL SQL / PROCEDURE testit(arg1 IN OUT BOOLEAN) IS BEGIN arg1:=TRUE; END; /*/ / the call from PHP **/ $stmt = OCIParse($connector->_connectionID, "BEGIN testit(:arg1); END;"); OCIBindByName($stmt,":arg1",$ret,10); OCIExecute($stmt); OCIFreeStatement($stmt); /*/ / the warning in french :-) **/ Warning: OCIStmtExecute: ORA-06550: Ligne 1, colonne 7 : PLS-00306: numéro ou types d'arguments erronés dans appel à 'TESTIT' ORA-06550: Ligne 1, colonne 7 : PL/SQL: Statement ignored in d:\apache\htdocs\iac\test.php on line 32 false (traduction of the warning : wrong argument number or type) /*/ -- Edit this bug report at http://bugs.php.net/?id=19687&edit=1
#19714 [Opn->Asn]: Using default user in OCI8 functions
ID: 19714
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Assigned
Bug Type: OCI8 related
Operating System: SunOS
PHP Version: 4.2.2
-Assigned To:
+Assigned To: maxim
New Comment:
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.
Previous Comments:
[2002-10-02 08:15:44] [EMAIL PROTECTED]
nevermind..should have read your report 2 times instead of one time.
[2002-10-02 08:14:41] [EMAIL PROTECTED]
You should be setting those environment variables in the SHELL not in
apache httpd..
See http://www.php.net/manual/en/ref.oci8.php for more information.
[2002-10-02 08:04:17] [EMAIL PROTECTED]
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
#19545 [Opn->Bgs]: Clipboard functions
ID: 19545 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: Feature/Change Request Operating System: Windows 95 PHP Version: 4.2.3 New Comment: Luciano, Doesn't the fact that in 6 years of PHP nobody talked about integrating windows clipbard suggest you that it is a minor need and we couldn't care less about it? There are COM functionalitites (can't these be used somehow?)... you can write a lovely Perl script that goes into your clipboard and interact with it via PHP's shell commands... and so on and so on. There are ways and ways to get your clipboard contents into a PHP script. Don't ask me more on how because I never even thought about it, but this should be possible as of now. Intergating this feature into PHP core today makes few or none sense. Unless there will be a high request and a clear view why it is needed. Maxim Maletsky Previous Comments: [2002-11-11 00:13:06] [EMAIL PROTECTED] Oh, I would if I could. But I'm afraid I do not have any competence at all for that. I started programming only one year ago. I know nothing of C, for example, except that PHP inherited a lot from it so they look alike sometimes. I wouldn't know where to start. I have no intention to put up any "battle". I just miss the feature very often, never saw any mention of it anywhere, not even in this bug/feature request section, and thought that maybe it was time someone asked for it. But if that's how the development team feels about it, case closed. Again, thanks for the reply. Luciano Espirito Santo [Note to passers-by and occasional readers: reading my previous message again, I noticed that I claim to "spend a lot of time writing in Perl". It sounds as if I actually spend a lot of time writing in Perl and that I am a Perl expert. What I actually meant was that I take too long to write anything in Perl, because I do not feel comfortable with it.] [2002-11-10 23:59:21] [EMAIL PROTECTED] You really have nothing to complain about until you submit a patch with this functionality. Then you can argue its technical merits. Asking us to implement a feature that none of us need is a rather impossible battle for you. [2002-11-10 23:52:38] [EMAIL PROTECTED] I'm disappointed to hear that. PHP is "intented primarely for web" (sic), but that doesn't have to rule out other uses. Several articles about the use of PHP as a shell scripting language have been written. I think it is just a natural step for anyone who makes extensive and intensive use of PHP. What is the point of php-cli.exe, anyway? I've been messing with several other languages lately, only in search of better integration with the Windows environment, so I can make better use of shell and/or automation scripts. I've tried Perl, Ruby, Tcl, Python and even stinky VB, and a few of these languages support the Windows clipboard. Not only that, they handle CGI functions but also seek better integration with the Windows environment. Especially Python. But I don't like Python. I don't want to write in Python. I could write in Perl and not feel miserable, but I spend a lot of time writing in Perl. I know PHP, that is the one I know. I feel comfortable writing in PHP. It is an excellent language, IMO superior to all others in several aspects, why does it (still) have to be regarded as a "Web-only" language? Why can't it extend into other territories, like Python is doing and becoming ever more popular as we speak? GTK is a good point. But GTK slows everything down a little, and not all shell applications require a GUI. I think it is just natural for any of these languages to evolve and extend its functionalities. PHP knows that. That's why PHP-cli was made, that's why its OOP (classes) implementation has been getting so much attention, that's why some effort has been made towards developing and improving its XML, COM and Windows API functions. Anyway, if there is any other reason for not implementing clipboard functions in PHP, fine. But let it be a more reasonable one. Because if clipboard functions are "completely off topic", what to say of COM and Windows API? And if it's "for Web use only", then why bother with PHP-cli? Thanks for the reply, at any rate. Luciano Espirito Santo [2002-11-10 18:10:44] [EMAIL PROTECTED] PHP is intented primarely for web - such feature would be completely off topic. I can only
#19778 [Opn]: Provide a way to remove http headers - like f.x. header("Pragma:")
ID: 19778
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Open
Bug Type: Feature/Change Request
Operating System: any
PHP Version: 4.2.1
New Comment:
Blind shot - this is impossible because headers get sent as soon I they
are encountered and thus you can override them by sending one more yet
cannot remove what you have already sent. I might be wrong, though.
If I'm not then lots close this one.
Previous Comments:
[2002-10-06 08:29:27] [EMAIL PROTECTED]
Sometimes it would be very handy to be able to remove a http header
that has already been set (for example, by the session module). Even
though header() allows me to replace a header, there is no way to
completely remove it.
Proposal:
header("Pragma:") could be used to remove a Pragma header - i.e. a
header given with no parms would remove the header.
Better:
New function like remove_header()
--
Edit this bug report at http://bugs.php.net/?id=19778&edit=1
#18003 [Opn]: trim() to accept arrays as argument
ID: 18003 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Linux PHP Version: 4.2.1 New Comment: Trim is a stricly string function, I don't see any need giving it an array as argument... It is so easy to do with php by applying array_walk() to your array or simply looping it... If your case really needs it tyou hen can just add it into sources yourself. On the other hand, there are already string functions that accept arrays in place of strings returning elaborated lements... Anyone? Leave this request or close it? Previous Comments: [2002-06-26 18:10:21] [EMAIL PROTECTED] +1 from me to make trim() understanding array as 1st argument and in that case trim all elements in array each by each. -- Edit this bug report at http://bugs.php.net/?id=18003&edit=1
#19545 [Opn]: Clipboard functions
ID: 19545 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: Feature/Change Request Operating System: Windows 95 PHP Version: 4.2.3 New Comment: PHP is intented primarely for web - such feature would be completely off topic. I can only picture GTK using something like that... Previous Comments: [2002-09-21 23:12:35] [EMAIL PROTECTED] -- [2002-09-21 17:29:30] [EMAIL PROTECTED] Hi. I've always wanted to be able to read from and write to Windows' clipboard. It is possible in Perl, but I prefer to use PHP. I do not intend to manipulate a Web site visitor's clipboard through CGI, I know it is impossible. It is for shell scripting only. PHP has such an incredible number of functions, it surprises me that no such functions have been made yet. Many thanks, Luciano Espirito Santo -- Edit this bug report at http://bugs.php.net/?id=19545&edit=1
#19687 [Opn->Asn]: ociexecute calling procedure with boolean out parameter
ID: 19687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Assigned Bug Type: OCI8 related Operating System: win 2k PHP Version: 4.2.1 -Assigned To: +Assigned To: maxim New Comment: I was planning to take over this one ... Previous Comments: [2002-11-10 00:18:56] [EMAIL PROTECTED] It is actually not a bug but rather the limitation of binding variables. We hope to add it some time soon. Maxim Maletsky [2002-10-01 06:54:18] [EMAIL PROTECTED] PROBLEM OCIEXECUTE WITH BOOLEAN OUTPUT PARAMETERS: The call to the following stored procedure (oracle 8.1.7) from php4.2.1 (as ampache module) does not work with a boolean parameter. It works fine however when I change boolean to NUMBER. / the procedure in PL SQL / PROCEDURE testit(arg1 IN OUT BOOLEAN) IS BEGIN arg1:=TRUE; END; /*/ / the call from PHP **/ $stmt = OCIParse($connector->_connectionID, "BEGIN testit(:arg1); END;"); OCIBindByName($stmt,":arg1",$ret,10); OCIExecute($stmt); OCIFreeStatement($stmt); /*/ / the warning in french :-) **/ Warning: OCIStmtExecute: ORA-06550: Ligne 1, colonne 7 : PLS-00306: numéro ou types d'arguments erronés dans appel à 'TESTIT' ORA-06550: Ligne 1, colonne 7 : PL/SQL: Statement ignored in d:\apache\htdocs\iac\test.php on line 32 false (traduction of the warning : wrong argument number or type) /*/ -- Edit this bug report at http://bugs.php.net/?id=19687&edit=1
#18449 [Opn->Sus]: OCI8 NLS_LANG set, but wrong result ('???')
ID: 18449 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Suspended Bug Type: OCI8 related Operating System: Redhat Linux 7.3 PHP Version: 4.2.1 New Comment: It's been here for a while and looks to me that the whole thing was kinda resolved. Classifying as Suspended. Maxim Maletsky Previous Comments: [2002-08-06 23:58:24] [EMAIL PROTECTED] ok now sorry i used wrong --php-config-file-path so the php.ini is missing. after corrected the php.ini problem, the nls_lang problem was overcome. just as you said, only NLS_LANG set in apachectl script works. it is not perfect solution for i can not use multi-language php-oracle couples in one apache+php server. thanks for your help. [2002-07-23 05:25:21] [EMAIL PROTECTED] can not work too, or, worse i did what you tell me, but it failed connect to oracle when nls_lang not set charset to 'american_america.us7asii'. this time ocilogon return ora-12705 'unsupported character set'! [2002-07-23 05:23:43] [EMAIL PROTECTED] can not work too, or, worse i did what you tell me, but it failed connect to oracle when nls_lang not set charset to 'american_america.us7asii'. this time ocilogon return ora-12705 'unsupported character set'! [2002-07-21 04:17:16] [EMAIL PROTECTED] don't use SetEnv in httpd.conf -> please set the oracle env-vars in you apache start (shell-)script. [2002-07-20 17:38:54] [EMAIL PROTECTED] sqlplus works nls_lang and database charset change to 'zhs16cgb231280' cannot work too The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/18449 -- Edit this bug report at http://bugs.php.net/?id=18449&edit=1
#19687 [Opn]: ociexecute calling procedure with boolean out parameter
ID: 19687 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] Status: Open Bug Type: OCI8 related Operating System: win 2k PHP Version: 4.2.1 New Comment: It is actually not a bug but rather the limitation of binding variables. We hope to add it some time soon. Maxim Maletsky Previous Comments: [2002-10-01 06:54:18] [EMAIL PROTECTED] PROBLEM OCIEXECUTE WITH BOOLEAN OUTPUT PARAMETERS: The call to the following stored procedure (oracle 8.1.7) from php4.2.1 (as ampache module) does not work with a boolean parameter. It works fine however when I change boolean to NUMBER. / the procedure in PL SQL / PROCEDURE testit(arg1 IN OUT BOOLEAN) IS BEGIN arg1:=TRUE; END; /*/ / the call from PHP **/ $stmt = OCIParse($connector->_connectionID, "BEGIN testit(:arg1); END;"); OCIBindByName($stmt,":arg1",$ret,10); OCIExecute($stmt); OCIFreeStatement($stmt); /*/ / the warning in french :-) **/ Warning: OCIStmtExecute: ORA-06550: Ligne 1, colonne 7 : PLS-00306: numéro ou types d'arguments erronés dans appel à 'TESTIT' ORA-06550: Ligne 1, colonne 7 : PL/SQL: Statement ignored in d:\apache\htdocs\iac\test.php on line 32 false (traduction of the warning : wrong argument number or type) /*/ -- Edit this bug report at http://bugs.php.net/?id=19687&edit=1
#17908 [Opn->Ana]: Can't retrieve info using OCIColumnIsNULL()
ID: 17908
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Open
+Status: Analyzed
Bug Type: OCI8 related
Operating System: Linux 7.1
PHP Version: 4.0CVS-2002-06-21
-Assigned To:
+Assigned To: maxim
New Comment:
true,
actually, what i noticed is that if you do a fetch *before* calling
OCIColumnIsNULL() you then get the right results.
/**/
$conn = OCILogon($user, $pwd, $db);
$stmt = OCIParse($conn, "select * from $table");
OCIExecute($stmt);
$nrows = OCIFetchStatement($stmt, $res); // adding this
$ncols = OCINumCols($stmt);
for ( $i = 1; $i <= $ncols; $i++ ) {
echo "NAME: " . OCIColumnName($stmt,$i) . "";
echo "TYPE: " . OCIColumnType($stmt,$i) . "";
echo "SIZE: " . OCIColumnSize($stmt,$i) . "";
echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does
not return any information
}
/**/
Will go to fix that.
Previous Comments:
[2002-06-21 14:20:29] [EMAIL PROTECTED]
I've tried using OCIColumnIsNULL() to retrieve info on which fields
were NULL/NOT NULL in an Oracle database table, and the function did
not return anything (using OCIColumnName, OCIColumnType, and
OCIColumnSize in the same program worked fine). The script below is a
simple example:
/**/
$conn = OCILogon($user, $pwd, $db);
$stmt = OCIParse($conn, "select * from $table");
OCIExecute($stmt);
$ncols = OCINumCols($stmt);
for ( $i = 1; $i <= $ncols; $i++ ) {
echo "NAME: " . OCIColumnName($stmt,$i) . "";
echo "TYPE: " . OCIColumnType($stmt,$i) . "";
echo "SIZE: " . OCIColumnSize($stmt,$i) . "";
echo "ISNULL: " . OCIColumnIsNULL($stmt,$i) . ""; //Function does
not return any information
}
/**/
--
Edit this bug report at http://bugs.php.net/?id=17908&edit=1
#18661 [Ver->Csd]: oci_logoff does not work
ID: 18661
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
-Status: Verified
+Status: Closed
Bug Type: OCI8 related
Operating System: Compaq Tru64
PHP Version: 4.2.0
New Comment:
No, it would be very wrong removing OCILogOff as it would due
compatibility issues. Lots of applications would end up with "Undefined
function" error messages. It should be mentioned in Docs, though.
Closed.
Previous Comments:
[2002-07-31 18:05:09] [EMAIL PROTECTED]
>From ext/oci8.c: (in the ocilogoff part)
"this function does nothing any more. server-connections get
automagiclly closed on request-end. connection handles will
'dissappear' as soon as they are no longer referenced. as
this module makes heavy use of zends reference-counting
mechanism this is the desired behavior. it has always been a
bad idea to close a connection that has outstanding
transactions. this way we have a nice-clean approach.
([EMAIL PROTECTED] 2110)"
Mainly documentation problem..maybe the function could be removed
altogether as it's dummy one anyway??
[2002-07-31 05:47:53] [EMAIL PROTECTED]
$oci8_conn = ocilogon($oci8_user, $oci8_pass, $oci8_sid);
echo("Conn after logon: "); var_dump($oci8_conn);
if (ocilogoff($oci8_conn)) {
$result = 1;
} else {
$result = 0;
}
echo("\nConn after logoff: ");
var_dump($oci8_conn);
echo("\n Result: $result");
Results in:
Conn after logon: resource(3) of type (oci8 connection)
Conn after logoff: resource(3) of type (oci8 connection)
Result: 0
--
Edit this bug report at http://bugs.php.net/?id=18661&edit=1
#18368 [Opn->Bgs]: Successful OCIExecute clears OCIError
ID: 18368 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Bogus Bug Type: OCI8 related Operating System: win2000 PHP Version: 4.2.0 -Assigned To: +Assigned To: maxim New Comment: Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php This is the way OCIError() should work. OCIError() returns the errors from the last Statement called, it does not buffer any previos errors that happened within the script and shows its last one. Perhaps you're right about the documentation. It should be saying: "return the error for the last Statement or Connection executed" instead of "return the last error occured" because this way it feels like if there was an error it'll get printed out regardless when it happened but as long as nothing failed after it. I will move this bug into the documentation issues. Thanks Eirik, Maxim Maletsky [EMAIL PROTECTED] Previous Comments: [2002-07-16 10:13:25] [EMAIL PROTECTED] I'm not really sure this is considered a bug, but in my view it's certainly an unexpected behaviour. Here's the case: In the end of a transaction of several insert/update statements, I'd like to check if all the statements executed without errors before deciding whether to commit or roll back: ... $stmt = ociparse($conn,$qry1); @ociexecute($stmt, OCI_DEFAULT); $stmt = ociparse($conn,$qry2); @ociexecute($stmt, OCI_DEFAULT); $stmt = ociparse($conn,$qry3); @ociexecute($stmt, OCI_DEFAULT); $stmt = ociparse($conn,$qry4); @ociexecute($stmt, OCI_DEFAULT); /* etc... */ if (!OCIError($stmt)) OCICommit($conn); else OCIRollback($conn); ... The problem is that if the execution of qry3 crashes and qry4 is OK, OCIError returns false and the transaction is committed. Since handling transactions must be the most useful area for an error-array like this, I'd expect the behaviour described in the documentation of OCIError: "Return the last error of stmt|conn|global". Now it returns the error of the last statement run - and if the last statement was successful, it returns false (regardless of what the last error was). Regards Eirik Olsen -- Edit this bug report at http://bugs.php.net/?id=18368&edit=1
