I cannot reproduce it.
Could you provide a little test script, please?

sure =) here are links to:

#the test, working (no returned value from function being assigned to variable) both in working form and in viewable form:
http://www.csmaster.org/art/initial_test.php
http://www.csmaster.org/art/initial_test.phps

#same script, with the line uncommented (attempt to store the returned value from ibase_query())
http://www.csmaster.org/art/initial_fail.php
http://www.csmaster.org/art/initial_fail.phps

#still available, server info
http://www.csmaster.org/test.php

you're welcome to connect to the database as shown, the firebird server should be accessible from the outside (and i just made a copy in case someone gets fancy.)

i know there's a lot of junk in those, but we spent a few hours trying various things, which all sorta wound up in the same file, to get it to let us do simple queries. it's my first time using php, but not firebird.

May you upgrade your interbase.c with that one in RC2 at www.php.net/~derick ?
 
and ... have you already look at http://www.php.net/manual/en/function.ibase-connect.php
there is an example showing how to loop in a resultset 

Daniela

i'll try the interbase.c thing, but if it's the change i've seen mentioned elsewhere in the recent bug reports/fixes (something about the "i've been naughty" section, changing what gets freed, etc.) then we've already got it (based on the diff i saw -- the links posted to it on cvs.something wouldn't work, 404.)

but i will try it, just in case. is 4.2 stable enough to use? or is -only- the interbase.c the part i want?

and yes, i have looked at the documentation. in several languages in fact (amusing that in french, the example stays the same, with translated text around it.) i found a few pages that had correct brackets for optional parameters (php.net's documentation on ibase_* is somewhat lacking in specifics.)

i still think the problem is centered around the return value from ibase_query: if i don't try to assign it to a variable, the script does connect, and it does get a value back from the database (so it's not something simple like a username/password problem.) 

the documentation says that ibase_connect, ibase_trans, ibase_query, etc. pretty much all return "int" but no integer i've ever seen when echoed says "Resource #3" ... 

also, i have no problem assigning the return value from the two other functions, both of which also return resources (integers, ha!)

am i missing anything else? i'll give interbase.c a whirl, and if that doesn't work, i might even upgrade to 4.2 all-around (might as well.) heck, i've got another server being setup, won't hurt it to try stuff out.

tried just the interbase.c file, didn't compile. tried all of 4.2.0RC2 from the QA website -- installs fine. (the test page will reveal that's what's running.) problem persists. the initial_fail.php script will still abort without sending a response. initial_test.php still works. any good ideas? a test script i could run to see if it's just me, the database server, the install of php, or something else entirely?

same as bug #15419 - #14558
the real problem was ibase_close(). Try to comment it out .... 
the issue you are talking about was fixed  some days ago.
(the day after RC2 release , I'm sorry :) ... but
you will be able to get fixed version in RC3 planned for tomorrow (April, 12)

Official Candidate release 4.2 is planned for April, 22nd 

and ... yeah... there is a bug in docs ....
ibase_connect(), ibase_query() etc do not return an int,
they return a resource ....."Resource #3" is correct.
I will report it as docs bug. 

Daniela

wooha! you're completely right on this one. the initial_repair.php script in the same location shows that it does work (forgot to make a .phps file, oh well.)

it worries me not to close the connection. is there something behind the scenes doing it, or shall i just live with the nasty feeling until it's fixed by RC3?

i'm still trying to understand how it happened. was the fact that i was storing a resource in a variable affecting the freeing process initiated by the ibase_close() call? that is, something to do with garbage collection mechanisms? now i'm just being nosy.

anything odd i ought to know about ibase support under php? i've been spoiled by a year of coding with builder/IBX, and haven't had to deal with simple protocols (base classes) across multiple db systems (no odbc for me!) i noticed something about ibase_prepare() vs. ibase_query(), that query() does a prepare() no matter what, even though interbase/firebird support other means, etc. i don't blame anyone, just curious. very curious person, me.

thanks for your help -- now i can let my team loose on it. wooha!

-philip

nevermind about the temporary solution -- i hadn't looked at the other bug numbers you provided. ibase_free_result() is what i mean, but i'm assuming that RC3 will be doing that for us behind the scenes. and ibase_close() is done automatically at end of script, correctly (as in, me not calling ibase_free_result() before the end of the script won't crash what happens automatically outside the script.) it's cool. thanks again.

-philip