ID: 40186 User updated by: tony at marston-home dot demon dot co dot uk Reported By: tony at marston-home dot demon dot co dot uk -Status: Bogus +Status: Open Bug Type: OCI8 related Operating System: Windows XP PHP Version: 5.2.0 Assigned To: tony2001 New Comment:
No, it's a place for reporting bugs, and this is a bug. I can write a database record containing a VARRAY column but I cannot read it back again. I can do this simple task with MySQL and PostgreSQL, but not with Oracle. Until you can prove that this simple task is possible with the aid of sample code - and do not waste my time by referring to the manual as the code samples there are next to useless - then this will continue to be a bug. If this is a problem caused by a deficiency in Oracle's OCI API then I suggest you contact Oracle (try christopher.jones at oracle dot com) and point out this serious deficiency. Do TOAD and Oracle SQL Developer use the OCI API? They don't have any problems with the reading and writing of VARRAY fields, so if they can do it why can't you? Previous Comments: ------------------------------------------------------------------------ [2007-01-22 12:21:00] [EMAIL PROTECTED] This is not a support forum. ------------------------------------------------------------------------ [2007-01-22 12:12:53] tony at marston-home dot demon dot co dot uk Then I suggest you provide a working example, based on the code which I supplied, which shows how I can write to and read from a VARRAY column on a database table. The example in the manual does not do this, so it is totally useless. Both TOAD and Oracle SQL Developer can handle VARRAY columns without a hitch, so don't tell me it can't be done. ------------------------------------------------------------------------ [2007-01-22 11:53:44] [EMAIL PROTECTED] >Unless you can show how my sample code can be made to >work, just like the SET datatye does with MySQL and the >ARRAY datatype does with PostgreSQL, this bug will remain open. As long as OCI API does not provide a certain way to distinguish between collections, objects and VARRAYS in OCIDefineByPos(), oci_bind_array_by_name() will remain the only method to fetch VARRAY data and this bug will remain bogus. If you know OCI API and can propose a patch - feel free to contact me. But I do not see any way to do it using the functions available. OCI API limitations are not PHP problems -> bogus. ------------------------------------------------------------------------ [2007-01-22 11:19:54] tony at marston-home dot demon dot co dot uk Your response is both unusable and impractical. The example in the manual for oci_bind_array_by_name() at http://www.php.net/manual/en/function.oci-bind-array-by-name.php shows how a VARRAY is built in memory from the contents of a database table. This is not how VARRAY fields are used in the real world. In my example I have a VARRAY field on a database table, not in memory, and I can write to this table without a problem, but I cannot read from it with gettingan error. Unless you can show how my sample code can be made to work, just like the SET datatye does with MySQL and the ARRAY datatype does with PostgreSQL, this bug will remain open. I expect, at the very least, to be able to read a record containing VARRAY fields into memory so that I can use the oci-collection methods to manipulate their contents. This would then make it similar to the way LOB fields are currently handled. I do NOT want a method which requires me to select the VARRAY and non-VARRAY fields with separate queries. Idealy I would like the contents of any VARRAY field returned to my program just like it is with TOAD or Oracle's SQL Developer, which is a string where each array is enclosed in parentheses. If that software can do it then why can't yours? ------------------------------------------------------------------------ [2007-01-22 07:37:05] [EMAIL PROTECTED] Use oci_bind_array_by_name() to fetch VARRAYs. ------------------------------------------------------------------------ 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/40186 -- Edit this bug report at http://bugs.php.net/?id=40186&edit=1
