Hi all,

As this point we have (I try to simplify, don't kill the piano player):
1) a deadlock on fbclient.dll because:
- PHP cannot use FB certified fbclient.dll lib, because it's not a MS
certified "practice" (or the like, whichever this means), so PHP must
build his own version.
- FB end-user applications and/or FB own isql.exe or other ./bin
utilities must use FB certified version of fbclient.dll

2) a small PHP test system, in which I see at first glance that without
*two* distinct sample databases it's impossible to test two phase
commit. But this is a problem allready discussed in firebird-devel
and/or firebird-doc AFAIR. Apart that you need also *two* distinct
firebird servers to have completely reliable tests IMVHHO, but this is a
completely other story ;)

The deadlock may be apparent from some POV: do we really need one and
only one client lib to server (if there are separated processes and
trough TCP/IP stack)?
To fb-devel the answer, I don't know; but, if true, seems to be a very
ugly hack, as I see it, because there is no instclient.exe distributed
with PHP, but only a fbclient.dll in php directories and in system
directories (or not ? and this is another question).
What happens if a Web Administrators deploy first PHP and then Firebird
or do it in the reversed order? "Please, see manual!" Well, ouch: all
ends in maintenaince nightmare...

Lester, if PHP fbclient.dll is not installed in system dirs nor in path
dirs but accessed locally through Windows DLL standard searching rules,
this assures that PHP accesses his own copy and other application
accesses system wide copy. Don't like it, but if you remove fbclient.dll
from PHP subdirs (like I'm doing now in Delphi for PHP with Interbase 8
gds32.dll) you have a PHP uncertified (read crashable from some POV) but
happy system.

What scares me is a Web server with PHP and Apache+Tomcat installed (for
different web applications, as you can easily argue).

Ciao.
Mimmo.