Justtechjobs.com Find a programming school near you






Online Campus Both


php-developer-list | 2000111

Re: [PHP-DEV] (Updated) Patch to add odbc_errno(), odbc_error(), odbc_clear_error() From: Andreas Karajannis (Andreas.Karajannis <email protected>)
Date: 11/06/00

Lars Torben Wilson wrote:
>
> Lars Torben Wilson writes:
> > > What about errors (connecting to a datasource) where you don't have a
> > > connection handle?
> >
> > I had originally thought about maintaining a global hash of the error
> > states & strings instead of having them part of the connection
> > handle--but that got into a whole bunch of thread-safety weirdness
> > and just seemed like a lot of code to do a simple thing.
> >
> > One idea would be that if i.e. odbc_errno() is called without a $dbh,
> > it would directly use SQLError() to find the last error to have
> > occurred at all.
>
> Of course, that's a braindead idea since you'd need a connection
> handle to do that. :)
>
> I'd also wanted to do it like mysql_errno(): if no handle is passed,
> then the default handle is used--which is consistent with the way most
> (all?) mysql_*() functions which take a connection handle work. I
> found an ODBCG global called defConn, which looked promising, but it
> never seems to get used--I'm not sure, but it looks like odbc_*()
> doesn't support default link ids like mysql_*().
>
> So what I've done now is simply copy every error state & message into
> a pair of strings in ODBCG. Now, when odbc_error(), odbc_errno(), or
> odbc_clear_error() are called without a link id, they will fetch/clear
> ODBCG(last_state) or ODBCG(last_errormsg), as appropriate.
>
> > > > It also shuts up the php_error(E_WARNING, ...) from within
> > > > odbc_sql_error(), but that's not really necessary...
>
> I've removed the #if PHP_DEBUG from this again...it seems reasonable
> that a PHP warning be issued, since the other db functions do it when
> something goes wrong.
>
> Does this come closer to addressing what you (Andreas) meant? Thanks
> again for any comments...
>

I think that all this copying and clearing of error information could be
avoided by simply writing a wrapper to SQLError().

Like

  array odbc_error([stmt_handle|connection_handle])

that would return SQLState and errormessage in an array. Or you separate
the functions for errornumber and errormessage. Depending on the
parameter passed (if any), SQLError() is called with the appropriate
arguments.
This is depending on whether the errorstack is cleared after a call to
SQLError() or not. Unfortunately, I can't find my old ODBC 2.x docs, and
in ODBC 3.5 SQLError() is deprecated and not described.

-Andreas 

-- 
Andreas Karajannis
GMD National Research Center for Information Technology
Schloss Birlinghoven, D-53754 Sankt Augustin
Phone +49 2241 142948

-- 
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, e-mail: php-dev-unsubscribe <email protected>
For additional commands, e-mail: php-dev-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>