Cherie,
What is this PRO*C bashing day or something? Sheesh!!!
I would appear from the -1458 error that there is something wrong with the
interface between Pro*C and PL/SQL. The -1458 indicates that "An attempt was
made to bind or define a variable character string with a buffer length less
than the two byte minimum required." I've only seen this particular error one
time and that was a long time ago. Some brainack put a char pointer into the
declare area with an initialized value of NULL and then attempted to select into
it. Anyway, if your developers want to forward the code and procedure/package
definitions over privately on Monday I'll take a look & see what I can find.
Dick Goulet
PS: Have a good weekend! :-)
Now where did I put that Guinness??
____________________Reply Separator____________________
Author: [EMAIL PROTECTED]
Date: 2/2/2001 1:28 PM
Dick,
In this case, it doesn't appear to be NLS or a network problem.
The developer has replied with the following:
When I ran this code, I got the Oracle -1458 problem:
EXEC SQL EXECUTE
BEGIN
EmployeePackage.GetNextDownloadEmployee;
:xversion := CommonGlobalPackage.Employee_Rec.VERSION;
:xemail_name := CommonGlobalPackage.Employee_Rec.EMAIL_NAME;
:employee_icn := CommonGlobalPackage.Employee_Rec.EMP_ICN;
:xprogram_load_flag :=
CommonGlobalPackage.Employee_Rec.PROGRAM_LOAD_FLAG;
:xboot_load_flag := CommonGlobalPackage.Employee_Rec.BOOT_LOAD_FLAG;
END;
END-EXEC;
It wasn't clear where the problem occurred in the code since the dbx debugger
doesn't step into the Pro*C code, so I divided the SQL EXECUTE into two parts
and re-ran the program.
EXEC SQL EXECUTE
BEGIN
EmployeePackage.GetNextDownloadEmployee;
:xversion := CommonGlobalPackage.Employee_Rec.VERSION;
:xemail_name := CommonGlobalPackage.Employee_Rec.EMAIL_NAME;
END;
END-EXEC;
dummy = 1;
EXEC SQL EXECUTE
BEGIN
:employee_icn := CommonGlobalPackage.Employee_Rec.EMP_ICN;
:xprogram_load_flag :=
CommonGlobalPackage.Employee_Rec.PROGRAM_LOAD_FLAG;
:xboot_load_flag := CommonGlobalPackage.Employee_Rec.BOOT_LOAD_FLAG;
END;
END-EXEC;
When this version of the code run, I get the Oracle -3106 error. As far as I
know,
the second version is legal; the compiler gives me no errors or warnings.
Any clues, Dick?
Cherie
[EMAIL PROTECTED] on 02/02/2001 02:24:39 PM
Please respond to [EMAIL PROTECTED]
To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
cc: (bcc: Cherie Machler/GELCO)
Cherie,
NLS_LANG and NLS_DATE_FORMAT. Things I've seen on this front.
Database created with US7ASCII & end user using
American_america.WE8ISO8859P1
Database set for NLS_DATE_FORMAT='DD-MON-YY'
and end user with NLS_DATE_FORMAT ='DD-MON-YYYY:HH24:MI
But in general 3106 is a catch all. Generally it means that something happen,
it does not know for sure, so it defaults. Other possibilities: bad network
cable(s), DNS server oops, router fowl-up, bad network card(s), noisy network
card(s), someone with a fat foot, or my all time favorite Access being used as a
multi user DB. That last one will send the data packet collision rate through
the ceiling.
Dick Goulet
____________________Reply Separator____________________
Author: [EMAIL PROTECTED]
Date: 2/2/2001 11:41 AM
We're getting this ORA-03106 error on 8.1.5 Oracle on Sun Solaris.
I looked it up on Metalink and there is quite a lot of information
there. I looked at one document in particular and found lots
of causes for ORA-03106. I'm going through the possibilities
one at a time and am wondering what one of the items means.
In item number 1 below it says to check for NLS incompatibilities.
Nothing real specific. Do they mean like the values for NLS_LANG
or something like that? I'm not sure and I don't have anyone to
follow up with. Anyone have a clue? Following is the excerpt:
RDBMS - Troubleshooting two-task common errors
==============================================
1. Check for NLS incompatibilities between the client and server. This is
a very popular cause of the ORA-03106 error.
2. Check the alert log and RDBMS trace files for any pertinent information /
errors that coincide with receiving the ORA-03106 error.
3. Try to get a testcase and reproduce the problem in-house.
4. If a testcase is not possible, ask for SQL*Net trace files, SQL traces, and
try setting event 3106 to obtain the error stack.
5. In extreme circumstances, this could indicate that a shared memory segment
used by Oracle is corrupted. You will have to shut down the database,
possibly using the abort option. Make sure all semaphores have been
released by using the IPCS command on Unix. Oracle uses semaphores to
control concurrency between all of the background processes (pmon, smon,
drwr, lgwr, and oracle shadow processes). Semaphores are also used to
control Two-Task communication between the user process and the shadow
process.
6. Try and narrow down the code that may be causing it. For example it might
have started to happen after increasing the number of parameters in a PL/SQL
block or when using certain values for bind variables, etc.
7. If we still do not make headway, file a bug under RDBMS, but we still may
need some or all of the above information as indicated above.
Thanks,
Cherie Machler
Gelco Information Network
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
