Sigh...I suck.
Foobared yet another patch.
Attached again.
Daniel
--- php-4.1.2/ext/oci8/oci8.c.orig Wed Mar 13 14:51:19 2002
+++ php-4.1.2/ext/oci8/oci8.c Thu Mar 14 10:02:48 2002
@@ -4090,16 +4090,35 @@
zval **arg;
oci_statement *statement;
oci_connection *con
I should have taken the time to make 100% sure these patches were
relatively bug free. I missed some obvious bugs in previous patches.
Hopfully these will test well.
I've not been able to compile the PHP binary in the latest CVS, so that
patch is untested, but it _seems_ ok, since the compile
DOH! I guess I made a few presumptions:
1) The user would never pass a NULL sql:
$conn = OCILogon ("bla", "bla", "bla");
$sql = NULL;
$stmt = OCIParse ($conn, $sql);
OCIExecute ($stmt, OCI_DEFAULT);
$error = OCIError ($stmt); <-- seg fault here
print_r ($error);
?>
This condition would caus
This patch simply adds the original query text as the "sqltext" element and
the error offset as the "offset" element. It was made against the latest
CVS. Hopfully it'll suffice. If not, please let me know.
Daniel
Markus Fischer wrote:
Of course the offset is fine. But if I were you,
On Wed, Mar 13, 2002 at 12:52:30AM -0800, Daniel Ceregatti wrote :
> Well, this leaves one question: Should I even bother passing the sql
> statement? Presumably, the developer will have access to the sql
> statement in the script/class already, so the offset _should_ suffice.
> This is actual
Well, this leaves one question: Should I even bother passing the sql
statement? Presumably, the developer will have access to the sql
statement in the script/class already, so the offset _should_ suffice.
This is actually what I originally implemented, but I thought I'd go the
extra kilometer
Agree! You could provide afunction for your html output and
make it an examle in the documentations - then everyone
knows how to make nice error messages and those needing
correct ones can do it too.
Besides that i often needed some time to see the asterix in
long statements (multiple subselects)
Of course the offset is fine. But if I were you, I wouldn't
put the asterisk into the sql statement; just provide the
offset. _This_ is the greatest flexibility you can provide
because all the information is passed unmodified to the
developer.
Serious environments need cus
I like the idea of having the sqltext in the return array, as well as
the offset. This is a very usefull tool for debugging oracle sql
queries. I believe its something that OCIError has been lacking.
Anyone that uses Oracle along with sqlplus, you get the * under the
broken portion of the query
Yes. An example of what would be in the array returned by OCIError would
be:
// Given the code below...
$conn = OCILogon (bla bla bla);
$sql = "select t.foo, t.bar from table t where t.id = 1";
$stmt = OCIParse ($conn, $sql);
OCIExecute ($stmt, OCI_DEFAULT);
$error = OCIError ($stmt);
//
On Tue, Mar 12, 2002 at 02:26:24PM -0800, Daniel Ceregatti wrote :
> How about doing what sqlplus does and simply add an asterisk at that
> point? I'm ok with rolling my own inside of the script by using the
> offset element. I simply think it'll do PHP users a service to have the
> "sqltext"
How about doing what sqlplus does and simply add an asterisk at that point?
I'm ok with rolling my own inside of the script by using the offset element.
I simply think it'll do PHP users a service to have the "sqltext" in the array
in _some_ form, even if only with an asterisk.
Your thoug
> have a feeling the lazy programmers (i.e. ME) will be happy with that
> instead.
>
> New patch attached.
>
> Daniel
>
> >
> >-Original Message-
> >From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
> >Sent: Tuesday, March 12, 2002 13:08
> >
py with that
instead.
New patch attached.
Daniel
>
>-Original Message-
>From: Andi Gutmans [mailto:[EMAIL PROTECTED]]
>Sent: Tuesday, March 12, 2002 13:08
>To: Walter A. Boring IV; [EMAIL PROTECTED]
>Subject: Re: [PHP-DEV] OCIError patch
>
>Hey,
>
>I'm not quit
Hey,
I'm not quite sure it's correct for the error message to print HTML itself.
It's probably more correct to do this from user land.
In any case, you should not be using malloc()/free() but emalloc()/efree().
If the request gets interrupted the memory will be freed if you're using
emalloc().
Ahh. very kewl patch Dan.
Walt
On Tue, 2002-03-12 at 12:48, Daniel Ceregatti wrote:
> Hi,
>
> I wrote a small patch to oci8.c's OCIError function which places the
> following tag:
>
>
>
> just before an error in a sql statement and adds the modified statement
> text into a new elem
Hi,
I wrote a small patch to oci8.c's OCIError function which places the
following tag:
just before an error in a sql statement and adds the modified statement
text into a new element called "sqltext" to the array returned by
OCIError, much the same way sqlplus adds an asterisk under
17 matches
Mail list logo
