RE: Porting PRo*C from 8.0.5 to 9.2.0
- From: "Goulet, Dick" <DGoulet@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Thu, 18 Mar 2004 16:13:17 -0500
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@xxxxxxxx]
Sent: Thursday, March 18, 2004 2:23 PM
To: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Bobak, Mark
Sent: Thursday, March 18, 2004 12:41 PM
To: oracle-l@xxxxxxxxxxxxx
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
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
