#26738 [Com]: PHP-OCI binding error

From: Date: Thu, 30 Jun 2005 09:33:09 +0000
Subject: #26738 [Com]: PHP-OCI binding error
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-81202@lists.php.net to get a copy of this message
ID: 26738 Comment by: svjoy at yandex dot ru Reported By: mbaranidharan at yahoo dot com Status: Assigned Bug Type: Feature/Change Request Operating System: * PHP Version: 4.3.4 Assigned To: tony2001 New Comment: Absolutely agree this is a serious problem. The way I am using to overcome this - temporary tables. But this requires another statement/cursor/parse and overhead. Many other languages HAVE the possibility. I cant understand why PHP doesn't. There is a great need for the way to pass structured data directly from PL/SQL environment to PHP (more preferrable, to native PHP array, but not fetchable Oracle-native). If I get such volume of structured data that can be allocated in RAM, why sholud I use cursors and other DBMS-related features? Why cant I get it in native PHP data type and forget about DBMS and release its resources? Previous Comments: ------------------------------------------------------------------------ [2005-06-14 17:19:47] tony2001@php.net Please *do not* add any comments to the report if they are not related to the current bug. Either create a new report (hint: use var_dump() in your code instead of echo()) or ask your questions somewhere else. This system is not a support forum and this report is not a forum topic. ------------------------------------------------------------------------ [2005-06-14 16:58:22] lukasz608 at o2 dot pl A some more: The function names in code above comes from PHP4, because i tried it also with PHP4. ------------------------------------------------------------------------ [2005-06-14 16:55:35] lukasz608 at o2 dot pl Hello, I have the code like this: " $stmt = ociParse($conn, "BEGIN ". " UTL_PC_CA_PATCH.patch_raport('TST', 21511, :data); ". "END;"); $data = ocinewcollection($conn, 'VARCHAR2TABTYPE'); ociBindByName($stmt, ":data", &$data, -1, OCI_B_NTY); ociExecute($stmt, OCI_DEFAULT); echo "SIZE: ".$data->size."<BR>"; echo $data->getelem(1); ocilogoff($conn); " The result is: " SIZE: " Can you explain me why $data is empty? 1. Type VARCHAR2TABTYPE is defined on users schema. 2. I'm sure that PL/SQL procedure returns table containg several elements in ":data". ------------------------------------------------------------------------ [2004-03-05 08:05:08] mbaranidharan at yahoo dot com Hi is there a solution available for this prob. Pls let me know. I have a c++ code which uses oracle OCI library to call the package and get me the result as array. Is there any detailed example available to create php extension in c++ which returns a array. Pls let me know. Thanks ------------------------------------------------------------------------ [2004-01-21 23:49:13] mbaranidharan at yahoo dot com according to my requirement iam not supposed to modify any existing package or procedure.It is strict that my out parameter is a plsql table type. When u try creating a type like that below is the result. SQL> create type tblEmpNo IS TABLE OF NUMBER(4) INDEX BY BINARY_INTEGER; 2 / Warning: Type created with compilation errors. SQL> show error Errors for TYPE TBLEMPNO: LINE/COL ERROR -------- ----------------------------------------------------------------- 0/0 PL/SQL: Compilation unit analysis terminated 1/18 PLS-00355: use of pl/sql table not allowed in this context one more thing i would like to say is bcoz of this prob i created a wrapper for this package in oracle which will take in plsql table and return me a ref cursor which works fine with PHP. But this i have kept is as a temporary solution. I need to solve it from PHP front. In OCIBindByname binding an array type is giving the problem. I checked in the other forums and i saw the same problem with other people too and this is open from year 2000 and is not solved. ------------------------------------------------------------------------ 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/26738 -- Edit this bug report at http://bugs.php.net/?id=26738&edit=1

« previous php.bugs (#81202) next »