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: Feedback
+Status: Open
Bug Type: OCI8 related
Operating System: Windows XP
PHP Version: 5.2.0
Assigned To: tony2001
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[2007-01-30 18:06:38] [EMAIL PROTECTED]
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?
------------------------------------------------------------------------
[2007-01-30 16:20:07] [EMAIL PROTECTED]
To both Tonys:
Please calm this discussion down, I think you are both getting on your
high horses, stuck in a loop repeating your respective entrenched
positions, and not even attempting to find a rapprochement.
To Tony Marston:
I understand that you have been unable to read a VARRAY the way that
you expected to, but so far you have shown no sign of attempting to
read it the way that tony2001 has suggested. To this extent, I
sympathise with his contention that this is a support problem and not a
bug. What you are looking for can be at most a feature request, but if
tony2001 is right and the OCI API currently provides no way to do this,
then this is indeed bogus.
I also see your point that the example in the manual illustrates a
completely different usage from the one you are looking for, but
tony2001's confident assertion that this is the call you need leads me
to believe that it should also do the job you want. (He is, after all,
the current maintainer of the OCI8 extension!)
Can you please try to read your records using oci_bind_array_by_name()
and oci_fetch(), and contribute back here with the results of your
attempt? I believe the code you want should look something like this:
$stmt = oci_parse($dbconn, 'SELECT favourite_food FROM x_person');
oci_bind_array_by_name($dbconn, $foods, 10, -1, SQLT_NUM);
oci_execute($stmt);
while(oci_fetch($stmt)) {
// here foods[] is an array of integers for current record
}
@tony2001 -- have I got that about right? (I'm unable to test as I do
not have an up-to-date enough version of Oracle available.)
------------------------------------------------------------------------
[2007-01-30 15:26:43] tony at marston-home dot demon dot co dot uk
As far as any reasonable person would be concerened this most
definitely is a bug. The Oracle database has a datatype called VARRAY
which is similar to the SET datatype in MySQL and the ARRAY datatpe in
PostgeSQL. The problem is that with your API I can write a record
containing a VARRAY column, but it is not possible to read it back
again. How stupid is that? Both MySQL and PostgreSQL can handle such a
simple operation, so why can't Oracle? Are their API authors more
competent?
Telling me that this is a "feature" and not a bug will do nothing to
calm me down. Entirely the opposite in fact. It is your job to provide
an API that allows PHP programmers to read and write all the datatypes
supported by the Oracle database, which you have singularly failed to
do. Blaming somebody else for your failure just shows how totally
unprofessional you are.
------------------------------------------------------------------------
[2007-01-30 15:00:34] [EMAIL PROTECTED]
>If you had said "Yes, this is a bug,"
There is no bug.
Missing features and bugs are absolutely different things.
>but the problem lies with the OCI API which is supplied by
>Oracle. Let me contact them to get this sorted out" that
>would have been a satisfactory response.
Please let me decide what to do.
Telling me what to say and what to do in SUCH a way does not help in
motivating me to help you.
If you think this problem should be reported to Oracle - please do it
yourself.
Not PHP problem -> bogus.
If you have anything else to tell me - you're welcome to write me using
my e-mail.
The report is bogus, so no sense to reopen it once again.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/40186
--
Edit this bug report at http://bugs.php.net/?id=40186&edit=1
