Zitat von "Lester Caine lester@... [firebird-php]"
<firebird-php@yahoogroups.com>:

> That is it does not conform to the standards introduced post 5.4 and
> it was perhaps lucky
> that it worked at all. Various PHP people would simply like to drop it!

I know. But what's the alternative? Firebird through ODBC? That'll be
interesting when it comes to blobs.

> I've not been able to access the code base myself for some time. Marius
> applied fixes around early 2015 to bring things in line, but neither of
> us really understand the PHP side of things enough to know just what is
> broken here although comments IN the code suggest it's something to do
> with the way the resources are stored now against how they were in 5.4
> days.

It seems the php team has got the same problem, just the other way round:

quote nikic@...:
"I'm not even clear on how some parts of this are *supposed* to work.
For example, what should this code do?

$link = ibase_connect($foo);
$link2 = ibase_connect($foo);
ibase_close($link2);

Should this ibase_close() call close all of $link, $link2 and the
default link? After all, all of these share the same connection."

To us this is clear:
- ibase_close($link2) must only close $link2 and nothing else
- there is no such thing as a default link
- link and link2 don't share the same connection. The code explicitly
requests two connections.

The question is how both sides (php - Firebird) could combine their knowledge?

> I understand that it needs fixing, but it is working fine for me so the
> incentive to spend even more time trying to get back in is not really
> there

I see. I wonder if the Firebird foundation could step in to collect
funds, I got confirmation that my company would sponsor that bugfix.
Both php and Firebird are far from being dead, and a well maintained
native driver would reflect that.

Volker