At 09:54 AM 1/03/2007, you wrote:

>I have a situation with PHP (hence the post to firebird-php) where
>ibase_close() is failing to close the specified connection, and it's failing
>silently, not returning any error messages as to my the close failed.
>
>Peering inside the source, it calls isc_detach_database (hence the post to
>firebird-support), but I'm having trouble finding the declaration for the
>isc_detach_database.
>
>The source inside PHP5.2.1 merely does the following:
>======================
>
>static void _php_ibase_close_link(zend_rsrc_list_entry *rsrc TSRMLS_DC) /*
>{{{ *
>/
>{
> ibase_db_link *link = (ibase_db_link *) rsrc->ptr;
>
> _php_ibase_commit_link(link TSRMLS_CC);
> if (link->handle != NULL) {
> IBDEBUG("Closing normal link...");
> isc_detach_database(IB_STATUS, &link->handle);
> }
> IBG(num_links)--;
> efree(link);
>}
>/* }}} */
>
>===============
>
>
> >From it's usage around the place, it appears to return true or false(nestled
>directly inside IF statements), so I presume if it failed, there's another
>function I can call to get any error text, like ERREXIT(status, 1), or
>something...

Transactions associated with the connection need to be either
committed or rolled back before calling isc_detach_database(). The
code sequence above doesn't seem to handle the case where a commit
can't happen and a rollback is required instead (but maybe the
rollback case is actually covered in the _php_ibase_commit_link() call).

For displaying error messages, try to find something that calls
isc_print_sqlerror() and isc_sql_interprete() - yes, it really is
spelt that way - or, in Fb 2, fb_interpret().

Do you have a copy of the IB 6.0 ApiGuide.pdf?

>Basically, I'd like to patch PHP5.2.1 to actually return any error codes
>from the detach process, instead of it dying silently...

It's possibly not "dying silently" but waiting for transactions to
finish. If the application code doesn't take care of it, about all
that's left is for the client to be recognised as abandoned. That
won't happen until after the prescribed keepalive timeout (2 hrs by
default or whatever you have it set to in your TCP configuration),
whereupon the logical connection would be considered
"dead". Eventually the dead transactions would be rolled back by the
engine and the mud would settle.

Helen