|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16523 $variable = ibase_query fails
Submitted: 2002-04-10 01:16 UTC Modified: 2002-04-11 14:40 UTC
Avg. Score:5.0 ± 0.0
Reproduced:0 of 1 (0.0%)
From: tigereye_philip at yahoo dot com Assigned:
Status: Closed Package: InterBase related
PHP Version: 4.2.0RC2 OS: linux (2.4.18, slackware 8)
Private report: No CVE-ID: None
 [2002-04-10 01:16 UTC] tigereye_philip at yahoo dot com
// successful:
  $stuff = ibase_fetch_row (ibase_query($sql_string));
  # we can get $stuff[0], rows are being returned

// not successful:
  $thingie = ibase_query($sql_string);
  # same statement, same file -- won't work.
  # if we comment this line out, the one above will work.
  # if this line does get executed, it fails. we can, for
  # that matter, grab the returned value and echo it! but
  # if for the life of us we try to assign it -into- a
  # variable so we can call ibase_fetch_row multiple times
  # (kinda handy) the script won't run.

// i'm not the sysadmin, but i'll try to get any info that would help out. we're talking to Firebird 1.0 (which supports all of Interbase 6.0's communications protocols) and i've not had any problems with the interbase->firebird conversion in other situations.

also tested: ibase_prepare gives us the same problem. if the return value is encapsulated in the call to ibase_execute, the script doesn't crash. if we grab it into a variable, and try to use that variable for the ibase_execute call, we don't ever get that far (the assignment kills it.)

i've checked for the often-mentioned patch to interbase.c, we have it.
for info on our server (in case you wanna know)


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2002-04-10 05:41 UTC]
I cannot reproduce it.
Could you provide a little test script, please?
 [2002-04-10 10:50 UTC] tigereye_philip at yahoo dot com
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:

#same script, with the line uncommented (attempt to store the returned value from ibase_query())

#still available, server info

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.
 [2002-04-10 11:52 UTC]
May you upgrade your interbase.c with that one in RC2 at ?
and ... have you already look at
there is an example showing how to loop in a resultset 


 [2002-04-10 14:26 UTC] tigereye_philip at yahoo dot com
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 ('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.
 [2002-04-10 23:46 UTC] tigereye_philip at yahoo dot com
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?
 [2002-04-11 04:30 UTC]
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. 


 [2002-04-11 14:35 UTC] tigereye_philip at yahoo dot com
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!

 [2002-04-11 14:40 UTC] tigereye_philip at yahoo dot com
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.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Feb 25 07:01:28 2024 UTC