Re: OCIError patch

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 and add the sql with the bold red HTML/asterisk in it. :) I'll grab the latest CVS and produce a unified diff that only adds the offset. Daniel Marcus Börger wrote:

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). So one could insert something of more flashy... marcus At 07:11 13.03.2002, Markus Fischer wrote:

    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 custom error handlers anyway.
    Putting HTML inside or modifying error messages this way is
    a bad thing [tm]. Just provide the raw components and
    everyone else can decide how he presents the data to the end
    user (that's the idea behind).

    And, for the patch, can you please make a unified diff
    against altest CVS ?

    - Markus

On Tue, Mar 12, 2002 at 03:19:27PM -0800, Walter A. Boring IV wrote :

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. I find it very usefull. If there is a general rule of not putting html inside return values for php internal functions, thats fine. But I still want an easy

way of

showing this type of info, without having to create my own wrapper function call to OCIError, just so I can highlight the broken

portion of

the query. my $0.02 Walt On Tue, 2002-03-12 at 15:08, Daniel Ceregatti wrote:

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); // What follows are the values of the elements of the array returned by OCIError (presuming "bar" is an invalid column it the table): $error["code"] = 904 $error["message"] = "ORA-00904: invalid column name" $error["sqltext"] = "select t.foo, t.*bar from table t where t.id = 1" $error["offset"] = 16 The PHP user then has the option of using either the "sqltext" element directly, or using the "offset" element and the $sql variable to create any output they see fit. I think this allows for the greatest felxibility, IMHO. Daniel Markus Fischer wrote:

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" in the array in _some_ form, even if only with an

asterisk.

Asterisk at what point? Specified by offset?

-- Please always Cc to me when replying to me on the lists. GnuPG Key: http://guru.josefine.at/~mfischer/C2272BD0.asc -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php