php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #22086 OCIBindByName causes problem if more than one Oracle statements are executed.
Submitted: 2003-02-06 02:15 UTC Modified: 2003-12-14 21:18 UTC
Votes:3
Avg. Score:2.7 ± 1.7
Reproduced:2 of 3 (66.7%)
Same Version:1 (50.0%)
Same OS:1 (50.0%)
From: gnitesh at yahoo dot com Assigned:
Status: No Feedback Package: OCI8 related
PHP Version: 5CVS-2003-02-06 (dev) OS: Red Hat Linux 7.3
Private report: No CVE-ID: None
 [2003-02-06 02:15 UTC] gnitesh at yahoo dot com
I have a script that combines various statements before it calls the OCIParse or OCIExecute.

For instance

Begin 
Insert into TABLEA(COLA, COLB, COLC) Values('VAL1', 'VAL2', 'VAL3'); Update TABLEB Set COLB = 'SOMEVAL' Where ROWID = :RID1 
End;

when I call an OCIBindByName for :RID1 as

OCIBindByName($oci_stmt,":RID".$i,&$this->arr_rowid[$i],-1,OCI_B_ROWID);

where I've defined each subscript of arr_rowid using OCINewDescriptor using the following

						$this->arr_rowid[$i] = OCINewDescriptor($this->obj_conn,OCI_D_ROWID);

OCIExecute gives me an error saying 

Warning: OCIStmtExecute: ORA-06550: line 1, column 221: PL/SQL: ORA-00933: SQL command not properly ended ORA-06550: line 1, column 93: PL/SQL: SQL Statement ignored ORA-06550: line 1, column 224: PLS-00103: Encountered the symbol "end-of-file" when expecting one of the following: begin case declare end exception exit for goto if loop mod null pragma raise return select update while with /var/www/html/crp/includes/dbconn.inc on line 333

I'm still investigating into the issue. Instincts tell me that the problem is due to multiple statements in 1 query so am all up on changing the entire class for all such occurances. However, the attempt to save database time by executing multiple queries together seems like is not destined to work. If it doesn't work, I'll get back in here with more info.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-02-06 07:44 UTC] maxim@php.net
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at
http://www.php.net/manual/ and the instructions on how to report
a bug at http://bugs.php.net/how-to-report.php


You forgot to add the semicolon `;' at the end of the second statement. Moreover - I doubt you can run this very thing he way you intended. Try the PL/SQL in SQL *PLUS before trying to run it from PHP.

Conclusion - it is Oracle's error message due your bad PLSQL design.

Closed as Bogus
 [2003-02-08 05:38 UTC] gnitesh at yahoo dot com
Thanx for the support. Agreed upon the missing ';' but it isn't really so in the actual case. The problem is something else. Oracle doesn't like the sytanx of my query because I don't have a declare statement for :RID1 but Oracle finds it perfectly alright if I use only 1 query and not more than one query as is the case here. Maybe it's handled internally within PHP when I call OCIBindByName in case of a single and not in case of multiple queries. That's just what I was inquisitive about. Why is it that I don't see an error when I have a single query with variables and OCIBindByName works ok but if I have more than 1 query, even before I reach the stage of calling OCIBindByName Oracle returns me an error.
 [2003-12-06 07:02 UTC] thies@php.net
if you still have that problem, plz send me a short 
-self contained- php script that shows your problem. i 
will look into it then.

(sidenot i don't actually think that the oci extension 
supports this kind of anon sql-block - you will have 
success if you move the block into a store-proc)




 [2003-12-14 21:18 UTC] sniper@php.net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 13:01:31 2024 UTC