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

Hello thies, On 05-Aug-00 15:46:36, 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?) I use this in Metabase OCI driver. Actually is for something very popular: count the number of rows in the result set. When the NumberOfRows function is called, the driver fetches all rows in the result set into a buffer array and returns the number of rows that were fetched. Actually I spotted this problem because a Oracle user reported it as a bug in Metabase driver. I added a new test case to Metabase driver class conformance test suite script and figured that there was a problem with OCINumCols because the user was asking first for the number of rows in the result set to display it before displaying the actual result data. > 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 So, when is that OCIInitialize() function called? In my scripts the putenv() calls are always made before any OCI calls. > 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 haven't tested much this code in PHP as Web server module but last time that I tested it didn't any problems like you mention. >> > 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. Well, OCINLogon is used in Metabase OCI driver when people explicitly request non-persistent connections, otherwise OCIPLogon is used. People that explicitly ask for non-persistent connections, are not looking for speed. On the other hand the problem os reused connections is that some scripts may be trashed by some fault caused by the previous Web server process that run a script that used the same connection. Anyway, I'm not sure what you mean with the above. Could you be saying that a script that uses two OCINLogon server connections could deadlock if both try to start mutual exclusion transactions? 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 --