Subject | Re: Trapping errors |
---|---|
Author | Myles Wakeham |
Post date | 2006-07-27T01:15:43Z |
> do you turn debug ON?Not directly. Only if I truly need to debug.
In EZSql, you can see why the errors are not being reported to the
application. Here's my modified version of your modified Firebird Query
method in EZSql....
// MOD-MW: Sets a custom error handler for Firebird related
errors
set_error_handler(array(&$this, 'firebird_errors'));
while ( $row = @ibase_fetch_object($this->result, IBASE_TEXT)
) {
$this->last_result[$i] = $row;
$i++;
}
Now, I've modified this myself but the problem is the @ibase_fetch_object
command which operates silently. Therefore if I'm trying to communicate
something from Firebird to my app, my app doesn't hear it. This appears to
include integrity constraints, exceptions, etc.
By adding my own error handler prior to this part of the method executing, I
do get the information and can deal with it my own way. Otherwise it is
just ignored.
Again, note that I do everything in stored procedures which means that I
don't get problems executing SQL to the database at the same point in time
that others may. I can normally execute my own SPs just fine. Its what
happens during the execution that is the problem and this appears to only be
noticed at the time when I fetch data back from the database.
Hence the need to intercept errors at this point and deal with them
seperately.
BTW, this is a hack on your modified EZSql class (modified for Firebird),
not the default class.
Regards,
Myles
===============================
Myles Wakeham
Director of Engineering
Tech Solutions US, Inc.
Phone (480) 451-7440
www.techsol.org