#40186 [Opn]: ORA-00932: inconsistent datatypes: expected CHAR got ARRAY

ID: 40186 Updated by: tony2001@php.net Reported By: tony at marston-home dot demon dot co dot uk Status: Open Bug Type: OCI8 related Operating System: Windows XP PHP Version: 5.2.0 Assigned To: tony2001 New Comment: You can and I've already pointed you out how to do it, but you don't want even to try. Previous Comments: ------------------------------------------------------------------------ [2007-01-30 19:21:43] tony at marston-home dot demon dot co dot uk MySQL's SET datatype and PostgreSQL's ARRAY datatype are identical in functionality to Oracle's VARRAY datatype in that they can hold arrays of values instead of single values. It is not unreasonable of me to expect to be able to write to a SET/ARRAY/VARRAY column and read that data back again. I can do this with the TOAD admin tool and Oracle SQL Developer, so why can't I do it with the OCI8 extension? ------------------------------------------------------------------------ [2007-01-30 18:53:53] tony2001@php.net >So just because I want to do something with Oracle that I >can already do with MySQL and PostgreSQL you call me >obstinate and pedantic? Oracle does not have SET or ENUM datatypes. Oracle does not support LIMIT clause. Oracle does not convert dates to strings and vice versa automatically. Oracle's SQL dialect is different from the dialects used in MySQL & PostgreSQL. There are much more things you CAN do in MySQL and/or Postgres, but CAN'T do in Oracle. Do you think they are PHP bugs too? ------------------------------------------------------------------------ [2007-01-30 18:34:41] tony at marston-home dot demon dot co dot uk So just because I want to do something with Oracle that I can already do wth MySQL and PostgreSQL you call me obstinate and pedantic? Is it unreasonable of me to want to read back from the database data which I have written? I think not. Your suggestion is impractical for me as it would require a great deal of effort to build a simple SELECT statement, one where I would have to step through every column name and process it with oci_define_by_name(). I don't have to do this with LOBs, so why should I have to do it with collections? Why is it not possible for the OCI8 extension to detect that a column is a VARRAY and return it as a collection object which I can then process with the OCI-Collection methods? It already has this option for LOB columns. Instead of me doing it in my code why can't the extension do it automatically instead of failing with error 932? ------------------------------------------------------------------------ [2007-01-30 18:06:38] mgf@php.net Don't be so blinking pedantic and obstinately blinkered! The code I suggested was just a test sample to see if you can read the VARRAY at all. If that works, I'm guessing you can combine additional columns in the SELECT with regular oci_define_by_name() calls to get more columns. Please try it. (As I said, I can't as I don't currently have access to up-to-date enough versions of either Oracle or OCI8.) ------------------------------------------------------------------------ [2007-01-30 16:53:03] tony at marston-home dot demon dot co dot uk The example using oci_bind_array_by_name() as shown in the manual is of no ue to me bacuse, as I have already explained in ths bug report, it shows how to construct a VARRAY in memory from the contents of a database table. It does not show how to write to a read from a table which contains a VARRAY column. In this respect it is totally useless. Your suggestion is also useless to me as it would require accessing the VARRAY column(s) separately from all non-VARRAY columns. This state of affairs does not exist with MySQL, PostgeSQL, nor any of the Oracle DB admin tools such as TOAD or Oracle SQL Developer. If those tools can manage to read and write VARRAY and non-VARRAY columns in a single operation, then why is it unrasonable for me to expect anything less from the OCI8 API? ------------------------------------------------------------------------ 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