Re: [PHP4BETA] lates libzend update did bad things

zeev - ok, nailed it down a bit more..... (without using call-by-reference) <? error_reporting(-1); $GLOBALS[ "DBView_Connection" ] = -1; function DBView_GetDB() { if ($GLOBALS[ "DBView_Connection" ] != -1) return $GLOBALS[ "DBView_Connection" ]; $GLOBALS[ "DBView_Connection" ] = ociplogon("digicol","digicol"); $stmt = ociparse($GLOBALS[ "DBView_Connection" ],"select 1 from dual"); echo "stmt = ".$stmt."\n"; // works!! if ($GLOBALS[ "DBView_Connection" ] == false) { // XXX do some retry here!! - or exit?? } return $GLOBALS[ "DBView_Connection" ]; } $a = DBView_GetDB(); $stmt = ociparse($a,"select 1 from dual"); //same stuff fails!!! echo "stmt = ".$stmt."\n"; ?> the DBView_GetDB call returns a db-connection (IS_RESOURCE in oci8.c) this script said (until today) : Content-Type: text/html stmt = Resource id #2 stmt = Resource id #3 starting today it says: Content-Type: text/html stmt = Resource id #2 PHP Warning: OCIParse: invalid connection 1 in tt on line 23 <br> <b>Warning</b>: OCIParse: invalid connection 1 in <b>tt</b> on line <b>23</b><br> stmt = so it might have to to with the $GLOBALS fix you did? regards, tc On Fri, 3 Sep 1999, Zeev Suraski wrote: > At 14:20 03/09/99 , Thies C. Arntzen wrote: > >On Fri, 3 Sep 1999, Zeev Suraski wrote: > > > > > At 10:45 03/09/99 , Thies C. Arntzen wrote: > > > >zeev, the lates update broke something... > > > > > > > > > > > ><? > > > >$conn=mysql_connect("127.0.0.1"); > > > > > > > >for ($inx = 0; $inx < 10; $inx++) { > > > > $r = mysql_db_query("test", "select * from phptest"); > > > > $array = mysql_fetch_array(&$r); > > > >// mysql_free_result($r); > > > >} > > > >echo "-----------------------end--------------\n";flush(); > > > >?> > > > > > > > >used to work - now says: > > > >PHP Warning: 2 is not a MySQL result index in mysql.php3 on line > > > >6 > > > > > > Well, why are you sending the result handle by reference? My API patch > > > doesn't make miracles, it keeps the existing C code in a way it would work > > > nicely, but not with weirdo stuff like that :) To avoid these errors, you > > > would have to actually modify the C code to be PHP 4.0 style (which I will > > > today, but I'll only do the MySQL module). > > > > > >sorry, that was a leftover.. it seems to work without the '&' - but have a > >look at #2230 - i have the same problem with some oracle-php-code i've > >written. > > > > > > > > > > Basically, mysql_fetch_array() expects to receive a copy of the result > > > handle, and it destroys it when it's done with it (transparently, > > > mysql_fetch_array() was never designed to do it). Since you now send it > > > the actual handle itself and not a copy - the handle that's destroyed is > > > the only handle, and the object is dead by the time PHP wants to use it. > > > >hmm got you - i will have a deeper look why my code stopped working this > >morning - again, i'm not the only one (#2230) - so some thing has > >changed;-) > > Basically, if you take any resource by reference, and you convert_to_long() > it - the resource goes bye-bye. With PHP 4.0, you shouldn't call > convert_to_long() on an expected resource, but instead, check whether the > type is IS_RESOURCE, bail out if it isn't, and just use it as-is. > > Zeev > -- > Zeev Suraski <zeev@zend.com> http://www.zend.com/ > For a PGP public key, finger bourbon@netvision.net.il > > > -- > PHP 4 Beta > > Thies C. Arntzen "One Big-Mac, Small Fries and a Coke!" Digital Collections Phone +49 40 235350 Fax +49 40 23535180 Hammerbrookstr. 93 20097 Hamburg / Germany