| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Porting PRo*C from 8.0.5 to 9.2.0
I would echo Tommy's comments. I have a small chunk of POR*C that I've had ever since Oracle 4. No problems in 9.2. The error you speak of I have run into when something gets copied into the .arr files and the .len field is not correctly set thereafter. This happens if you use the variable in a into or set clause as well as anywhere in the where clause. But then that happen in pervious versions as well.
Dick Goulet
Senior Oracle DBA
Oracle Certified 8i DBA
-----Original Message-----
From: Clark, Tommy R [mailto:TOMMY.R.CLARK_at_saic.com]
Sent: Thursday, March 18, 2004 2:23 PM
To: oracle-l_at_freelists.org
Subject: RE: Porting PRo*C from 8.0.5 to 9.2.0
I assume that you are talking about using these VARCHAR variables as part of the INTO of a select statement. I have some PRO*C code that I have been maintaining since Oracle 5.1 and it is currently running on Oracle 9.2.0.3. I do not remember having to go back and initialize the .len to 0 before the select. Of course, if you are using any of these as bind variables in the where clause, I would hope that Oracle would complain if they were not initialized.
The most common cause of this and similar errors that I have had is defining a variable too short and having something overwrite the .len of another variable. Is it possible that in the change of versions that something may have happened to change the word boundary alignment of the VARCHAR structure? Before it might have left a gap which absorbed the string that was too long and now it does not.
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Bobak, Mark
Sent: Thursday, March 18, 2004 12:41 PM
To: oracle-l_at_freelists.org
Subject: Porting PRo*C from 8.0.5 to 9.2.0
Hi all,
Our database is currently at 8.1.7.4, but since at least some of our clients are SGI, and there were numerous issues w/ Pro*C and 8.1.7 on SGI (n32, 64-bit, etc), we chose to stay on 8.0.5 for the clients.
Now, we are in the position of upgrading the database AND the client side to 9.2.0.x (where x is probably 4, but may be 5, if it's released soon). As part of this upgade, our clients are moving from SGI to Linux (as SGI is not at all supported starting at 9.2.0).
Ok, that's the background, now, on to the problem:
Very many places in our code, we have declarations that look like:
varchar po_output_variable[AO_SOME_LENGTH];
Now, I'm aware that the varchar is replaced by a structure definition by the Pro*C precompiler. There's a '.len' and '.arr' component to the structure. However, neither of these is initialized. My problem is that when a call to the database happens, if the structure is uninitialized, Oracle (may) raise ORA-1458 "invalid length inside variable character string".
This never happened w/ the 8.0.5 client. I'm not too keen on hand editing several hundred Pro*C files to add initialization to all VARCHAR host variables.
Does anyone have any ideas/thoughts/suggestions? (Other than continuing to use 8.0.5 client code? ;-))
Thanks in advance for any suggestions,
-Mark
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.htmlput 'unsubscribe' in the subject line.
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request_at_freelists.org
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.htmlput 'unsubscribe' in the subject line.
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request_at_freelists.org
 |
 |