Re: PHP 4.0 Bug #5888: Can't access result columns meta information after reaching the end of result.

On Sat, Aug 05, 2000 at 03:14:35PM -0300, Manuel Lemos wrote: > Hello thies, > > On 05-Aug-00 07:30:45, you wrote: > > >> Try the following script and see that after attempting to fetch the row > >> after the last in the result set, OCINumCols() no longer returns the right > >> value. This problem did not exist in PHP 4.0.0 . > > > sorry - please do not depend on OCINumCols to be valid after > > the cursor is read. we need to free all cursor related suff > > when the end of the cursor is reached in order to support > > nested tables and REFCURSORS in the driver *without* carrying > > to much complexity into the script level. > > I don't contest that, but I'm not sure what it really means. Why couldn't > Column metadata be freed on OCIFreeCursor or there a new result set is > reached (if that is what you mean)? no. it could be implemeted so that most meta-data information stays valid even after the all the data of the cursor has been read -but- i simply don't have the time to implement that. so right now this is a known *tiny* incompatible change that i'm willing to accept. (as i don't think it will affect people - why would you want to get a columns name *after* you read all the data?) > > > >> <? > >> if(!function_exists("OCINLogon")) > >> { > >> $this->last_error="Oracle OCI API support is not available in this PHP > >> configuration"; return(0); > >> } > > > i would *not* recomment using putenv to set any of those - we > > had all kinds of problems reported that went away by setting > > the oracle-related env-vars _before_ apache was started! > > Couldn't that be due to a bug in putenv that was trashing putenv string > argument, that Jouni fixed right before PHP 4.0.0. release? That was > affecting scripts that executed the same PHP code more than once and were > passing constant strings to putenv(), like in this case, but in my real > test code (Metabase oci driver class) the strings are not constant. no - the problem is that the initial call to OCIInitialize() (this initialized the oracle-oci environment) is done in the MSTARTUP call - and that is way _before_ putenv'ed stuff would be in effect. the problem here is that some oci-stuctures (in the oracle-core) are only initialized once, and that is done in OCIInitialize()! if your code works with PutEnv - fine, but a lot of people have had problem when using putenv that dissapeared when setting the env-vars _before_ they started apache. > > I really need to set the variables in the PHP code because this is being > used in Metabase Oci driver and it really needs to be as much platform > independent as possible, so I can't assume that people may be able to set > the variables before running any particular server. sorry, AFAIK you'll have to. (if you want stable, predictable operation against oracle). there might be some light at the end of the tunnel as 8i has introduced some new calls to create/initialize new environments - but that's not supported withing PHP as of now. > > >> putenv("ORACLE_HOME=/home/oracle/u01"); > >> putenv("ORACLE_SID=dboracle"); > > > > OCINLogon is the slowest connection mode possible, it always > > creates a new transaction context on the server. i don't > > think that any other php-db-driver allows this level of > > transaction isolation - use it only when needed! > > That was on purpose. I only use OCINLogon when I deliberately want to open > a non-persistent (reused) connection. OCILogon does that better (and faster)! plz understand the transaction-isolation sample from the manual -plus- understand that no other DB driver supports this level of isolation AFAIK. tc > > >> > >> if(($connection=OCINLogon("SYS","change_on_install","dboracle"))) > >> { > > > > OCINewCursor() is only needed for initilalizing bind > > valriables. > > >> if(($cursor=OCINewCursor($connection))) > >> { > > You are right. I guess I copied this from example code without noticing > that it was not needed. Thanks for the warning. > > > Regards, > Manuel Lemos > > Web Programming Components using PHP Classes. > Look at: http://phpclasses.UpperDesign.com/?user=mlemos@acm.org > -- > E-mail: mlemos@acm.org > URL: http://www.mlemos.e-na.net/ > PGP key: http://www.mlemos.e-na.net/ManuelLemos.pgp > -- -- 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