Program too large

Hi, I am using Forms Developer 6.o and i encountered a "program too large" error on one of my program units. How can I resolve this? Does the size pertain to the number of commands used or the lines used in the program units? Thanks

Read Metalink note 99882.1: PL/SQL Size Limits Explained
Solution would be to split your program unit.

Similar Messages

ORA-06553: PLS-123: program too large on import

Hi,
I import a dump file from a 9.2.0.4 to an other 9.2.0.4 database.
On some importing table, I have this error :
. . importing table "PS_TL_PAYABLE_HIST" 0 rows imported
IMP-00017: following statement failed with ORACLE error 6540:
"DECLARE SREC DBMS_STATS.STATREC; BEGIN SREC.MINVAL := NULL; SREC.MAXVAL :="
" NULL; SREC.EAVS := 0; SREC.CHVALS := NULL; SREC.NOVALS := DBMS_STATS.NUMAR"
"RAY(); SREC.BKVALS := DBMS_STATS.NUMARRAY(); SREC.EPC := 0; DBMS_STATS.SET_"
"COLUMN_STATS(NULL,'"PS_TL_PAYABLE_HIST"','"TL_QUANTITY"', NULL ,NULL,NULL,0"
",0,0,srec,0,0); END;"
IMP-00003: ORACLE error 6540 encountered
ORA-06540: PL/SQL: compilation error
ORA-06553: PLS-123: program too large
IMP-00017: following statement failed with ORACLE error 6540:
"DECLARE SREC DBMS_STATS.STATREC; BEGIN SREC.MINVAL := NULL; SREC.MAXVAL :="
" NULL; SREC.EAVS := 0; SREC.CHVALS := NULL; SREC.NOVALS := DBMS_STATS.NUMAR"
"RAY(); SREC.BKVALS := DBMS_STATS.NUMARRAY(); SREC.EPC := 0; DBMS_STATS.SET_"
"COLUMN_STATS(NULL,'"PS_TL_PAYABLE_HIST"','"BILLABLE_IND"', NULL ,NULL,NULL,"
"0,0,0,srec,0,0); END;"
IMP-00003: ORACLE error 6540 encountered
ORA-06540: PL/SQL: compilation error
ORA-06553: PLS-123: program too large
IMP-00017: following statement failed with ORACLE error 6540:
"DECLARE SREC DBMS_STATS.STATREC; BEGIN SREC.MINVAL := NULL; SREC.MAXVAL :="
" NULL; SREC.EAVS := 0; SREC.CHVALS := NULL; SREC.NOVALS := DBMS_STATS.NUMAR"
"RAY(); SREC.BKVALS := DBMS_STATS.NUMARRAY(); SREC.EPC := 0; DBMS_STATS.SET_"
"COLUMN_STATS(NULL,'"PS_TL_PAYABLE_HIST"','"OPRID"', NULL ,NULL,NULL,0,0,0,s"
"rec,0,0); END;"
IMP-00003: ORACLE error 6540 encountered
ORA-06540: PL/SQL: compilation error
ORA-06553: PLS-123: program too large
IMP-00017: following statement failed with ORACLE error 6540:
"DECLARE SREC DBMS_STATS.STATREC; BEGIN SREC.MINVAL := NULL; SREC.MAXVAL :="
" NULL; SREC.EAVS := 0; SREC.CHVALS := NULL; SREC.NOVALS := DBMS_STATS.NUMAR"
"RAY(); SREC.BKVALS := DBMS_STATS.NUMARRAY(); SREC.EPC := 0; DBMS_STATS.SET_"
"COLUMN_STATS(NULL,'"PS_TL_PAYABLE_HIST"','"CLASS_FLD"', NULL ,NULL,NULL,0,0"
",0,srec,0,0); END;"
IMP-00003: ORACLE error 6540 encountered
ORA-06540: PL/SQL: compilation error
ORA-06553: PLS-123: program too largeThe import command is simple :
NLS_LANG=american_america.utf8
export NLS_LANG
/etc/mknod /data/ora/P97RPRD/e01/tube p
uncompress -c /data/ora/P97RPRD/e01/backup.dmp.Z > /data/ora/P97RPRD/e01/tube &
imp SYSTEM/MANAGER FROMUSER=P97RPPRD TOUSER=P97RPRD FILE=/data/ora/P97RPRD/e01/tube LOG=/data/ora/P97RPRD/adm/dbalog/importP97RPRD.logFrom where does it come ?
If I well understand, this is the import of statistics, but why this error ?
Is I can avoid this error if I import with STATISTICS=none ?
Thanks in advance,
Nicolas.

Hi please check this,
Select * from dba_objects where object_name = 'DBMS_STANDARD';
The standard package may be invalid.
reran catproc.sql This caused the dbms_standard package to become valid once again.
HTH,
Thomas.

"program too large" on package compile

Hi,
I am trying to compile a package (which has around 3000+ lines), and I am getting an error "program too large".
I believe I would need to split into 2 packages, but is there any other solution than splitting the code?
I am building a dynamic package from here using system.ad_ddl. Can I use system.ad_ddl in two different packages and in the end create the object in one of the packages? (will it take the statements added from both the packages?)
Thanks,
Sharad

system.ad_ddl is not a Oracle documented program unit name. How did it get into the SYSTEM schema?
Can you post a Oracle doc link to this code unit where it is available?

'Program Too Large' error in PL/SQL

How to get rid of 'PLS-00123 - Program Too Large' error ? This comes when the program to be compiled goes more than a certain limit.
One way is to make the program modular by splitting the logic in several Procedures/functions and packaged procedures.
Is there any other way to fix this problem ? Any variable or parameter which we can set to get rid of this error.
Thanks.

There are some linits on program size and so the obvious thing to do (as the error suggests) is to break the program unit. It makes it a lot easier to maintain as well.
Regards
Grant Ronald
Forms product Management

Deploying Dimension give PLS-00123 error (program too large)

Hi,
I'm using OWB 10.2 with a Windows 10g 64bit environment. I successfully deployed a dimension to my target data warehouse. Later, I went back to the dimension and added 5 dimension roles to it and redeployed. When redeploying with the dimension roles, I get the following error:
ORA-06550: line 1495, column 81:
PLS-00123: program too large (Diana nodes)
The recommendation is to break up the PL/SQL code according to the error message but this is generated code so I'm out of luck there. Any suggestions or settings that might alleviate this?
TIA,
mike

In past DW efforts (Informatica, Sybase IQ/Oracle/DB2), I've used synonyms or views against a base time dimension to handle the "roles" so that each looks like a distinct dimension. I'm trying to do the equivalent from OWB. Initially the DW will be relational, but I may generate some cubes from the DW in the future.
Not sure what you mean by a "pure relational" solution. We will be using discoverer in our environment, but not exclusively. There will be other reporting tools in use as well.

ORA-06553: PLS-123: Program too large

Hi,
I have 2 databases, the development database (9i) and pruction database (10g). I have the same programs on the databases, but when I try to execute the package1.program1 for 3000 records in 10g, result in a error:
ORA-06540: PL/SQL Compilation error
ORA-06553: PLS-123: Program too large
9i is OK.
The program package1.program1 have a lot of DYNAMIC-SQL.
I need help. (Sorry for my English)
Thanks,
Ivan

Hi please check this,
Select * from dba_objects where object_name = 'DBMS_STANDARD';
The standard package may be invalid.
reran catproc.sql This caused the dbms_standard package to become valid once again.
HTH,
Thomas.

Strange Error: PLS-00123:program too large

Hi,
I was wondering whether, when using Oracle Application Database configuration tool, anyone has seen the following:
error occured during batching: ORA- 06550: live 11024, column 1: PLS-00123:program too large.
This occured when trying to create a new OLT schema on a remote database (Oracle 10g 64 bit, running on Solaris 9).
I've never seen this particular error before......
Any ideas would be welcome
Regards
Wayne.

Hi JB,
I've created an SR....let see what happens :)
Wayne.

Get an error 123 (Program Too Large)

Hi there,
I am just try to modify procedure in oracle 6i and after or while modification when we compile this program then we get an error 123 (Program Too Large) .
any one have ideal about that how can i solved it.
Haider Ali

hi,
(Program Too Large) .Please use search option about this topic. There will be lots of posts regarding this.
you can split the code into procedures and make a call in this program unit.
share the code you have written.

Program too large error

Hello Friends
I am using oracle forms 6.
I write code on button's WHEN-BUTTON-PRESSED event and then compile that trigger at that time i am getting error
"program too large"
Ofcourse on that event coding is large but what i have to do to avoid that compilation error.
i serched for solution then i got that
.ENABLE COMPILER SIZECHECK write this command but where to write or to set this property?
Can any one know then please help me.
Or if another solution then i appreciate with that solution.
Thanks in advance...

Before you play with any compiler parameters (which is not recommended) you might want to try the following first.
1- Remove all unnecessary lines from the code, like carriage returns.
2- Remove all extra spaces, or comments you do not need.
But most importantly, remove your code from the trigger and put it in an PL/SQL Program Unit in your form and call it from the WHEN-BUTTON-PRESSED trigger.
Also you can break your code into smaller procedures so you can call it separately.
Regards,
Tony

PLS-00123: Program too large error

Hi,
We have been getting a 'PLS-00123: Program too large' error while compiling a particularly large package on a *11g database*. The package has around 15000 lines of code. We are compiling the package using a third party IDE(PL/SQL Developer).
I went through AskTom's note (http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:571023051648) and Metalink Note#62603.1 which helped in understanding the problem. However, could not resolve the problem since modifying the structure of the package was not an option.
Someone from the team contacted a DBA regarding this who in turn suggested that we compile the package in SQL*Plus. We did as suggested on a *10g client* connected to the 11g database and the package got compiled.
I cannot understand why we encountered the error while compiling the package in PL/SQL Developer but not while doing the same from SQL*Plus. Can anyone please explain this or point out some helpful documents?
Regards,
Sujoy

Hope this link helps..
http://forums.allroundautomations.com/ubb/ubbthreads.php?ubb=showflat&Number=10265&PHPSESSID=2e3c1b028a66500ae8a1730abc88b993

Any workaround for Program too large error?

Dear All,
When a program of size 5432 lines compiled(it is having 4 cursor definitions attached to huge select statement from multiple tables), getting an error "PLS-00123 Program too large". Oracele error manual suggests to split the program. Is there any other way to make it work without splitting? (I mean setting some system variables?)
Thanks
Sheeba

What it means by splitting can be achieved by somethingon the lines of changing
PROCEDURE one is
command1;
command2;
command3;
command4;
command5;
command6;
END;
PROCEDURE one is
PROCEDURE onea IS
command1;
command2;
command3;
END
PROCEDURE oneb IS
command4;
command5;
command6;
END
onea;
oneb;
END;
If the problem is the size of the cursors all in the declare section, then you may be able to declare them initially as ref cursors, then having four separate sub procedures opening them so that the text of the cursors are in the subprocedures.
Alternatively, stick the selects into views.

Exporting from HTML DB 1.4 to 2.0 - "Program too large (Diana nodes)"

Hi
I exported an HTML DB 1.4. into a script and got an error while trying to execute it.
The script itself is over 800 kb and consists of 25 000 lines. However, it is divided into begin-end blocks.
If I start the script in HTML DB 2.0 I get an error:
"Program too large (Diana nodes)"

Sorry, it should have been HTML DB 1.4 <b>application</b>.
The application causing this problem has also a page with about 200 items, so I hope that after I have splitted this problematic page into multiple pages, this "program too large" problem would also solve.

Pls-00123: program too large

When I compile my 11400 lines package in the sql developer I get the error: pls-00123: program to large.
When I run the script for the package in the sql*Plus tool it works fine.
Any ideas? Are there any restrictions for packages in the sql developer?
Thanks - Andreas

Some more details:
If i try to compile (no debug) my 4400 (it grew) line package body it compiles via sql*plus, sql worksheet, or the code editor in sql developer.
If i try to compile for debug it errors in all three... therefore the compile error for me is coming from the database. As a workaround, I can compile for debug from sql*plus or the sql worksheet using 'reuse settings' after i have done a non-debug compile successfully..
alter package package_name compile debug body;
--errors
alter package package_name compile body;
--success
ALTER PACKAGE package_name COMPILE DEBUG BODY REUSE SETTINGS;
--success only if the body was already compiled successfully
whew..
Finally, if i have compiled for debug with 'reuse settings' and attempt to debug it in sql developer, it will throw the beloved ora-600 error.. again.. probably originating from the database. My dba has told me to log a tar on this one.
Eric
SQL*Plus: Release 10.2.0.1.0 - Production on Mon Jun 5 10:39:28 2006
Copyright (c) 1982, 2005, Oracle. All rights reserved.
Enter password:
Connected to:
Oracle9i Enterprise Edition Release 9.2.0.5.0 - 64bit Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.5.0 - Production
Message was edited by:
EricH - added database info

PLS-00123: program too large on 9i with 4200-lines-trigger

Just ran into another problem:
I work with Oracle 9i. I have a trigger with 4123 lines of code. And I get PLS-00123 when I try to create the trigger.
I've read that since Oracle 8.x (I can't remember the exact version) a program can have up to 6 mio lines of code, but I get the exception after line 3297.
Thanks for your help =)

Ok, I'll try to explain everything as best as I can.
Basically I have 4 tables. 2 of them are used to record the changes and 2 for configuration.
The changes for a row will be saved as one entry in CHNGHIS_HDR an entry in CHNGHIS_DTL for every changed column
CHNGHIS_HDR
     TLBID --- the id of the table in which the rows were changed
     ITEMCNT --- number of the rows that were changed
     TYPE --- can be N (new), C (change), D (delete), I (inherit) and E (inherit delete)
     HEADERID --- the id of the header which the detail belongs to
     COLID --- the id of the column
     COLNAME --- the column name
     OLDVAL
     NEWVALCHNGHIS_TAB holds the name of the table that should be tracked.
CHNGHIS_TAB
     TBLID --- the table id
     TABNAME --- the table name
     ACTIVE --- is the CHNGHIS_COL holds the columns that should be tracked. If there are no entries for a table, all columns will be recorded.
CHNGHIS_COL
     TABNAME --- the name of the table
     COLNAME --- the name of the columnIn the old version, our program inserted the necessary rows into CHNGHIS_HDR and CHNGHIS_DTL. But now they want to do it with triggers. And they want to be able to enable/disable recording no tables and columns.
So every time an insert/update/delete is executed, I have to record these changes in CHNGHIS_HDR and CHNGHIS_DTL. The trigger has to check for every column if it should be recorded (entry in CHNGHIS_COL). And 180 columns in a table cause a lot of code =(
At the moment I use this code for every column
/* column EXTERNALORDERNO */
    if inserting or deleting or (updating and not :old.EXTERNALORDERNO = :new.EXTERNALORDERNO) then
        select count(*) into counter from chnghis_col where tabname = 'MATERIAL' and colname = 'EXTERNALORDERNO';
        if logColCounter = 0 or counter > 0 then
            colGid := getGID('MATERIAL', 'EXTERNALORDERNO');
            if inserting then
                writeHistoryDetail(headerId, columnsChanged + 1, colGid, 'EXTERNALORDERNO', null, ''||:new.EXTERNALORDERNO, udpstmp);
            elsif updating then
                writeHistoryDetail(headerId, columnsChanged + 1, colGid, 'EXTERNALORDERNO', ''||:old.EXTERNALORDERNO, ''||:new.EXTERNALORDERNO, udpstmp);
            elsif deleting then
                writeHistoryDetail(headerId, columnsChanged + 1, colGid, 'EXTERNALORDERNO', ''||:old.EXTERNALORDERNO, null, udpstmp);
            end if;
            columnsChanged := columnsChanged + 1;
        end if;
    end if;@Peter: we have over 300 tables -> over 300 triggers. We decided to use triggers (and when I say 'we', I mean the head of software development). If the decision was mine, I would use Workspace Management. But hey, I finished school 1 month ago and I just work here to pay the rent when I'm forced to enter the army, so there is no chance that they listen to me ;)

FI-SL data package too large on delta

Hi Guys,
I`m loading data from FI-SL total extractor ( 3FI_SL_xx_TT )
No problem with Delta Init but when we try to load a regular delta there is some problem with the size of the packages, there are totally irregular package sizes: 70.158, 52.398, 299.784, 299.982, 57243, .. So I`m getting TSV_TNEW_PAGE_ALLOC_FAILED error on transfer from PSA to InfoCube.
Unfortunately we have to load a heavy bunch of data on delta because they want this data monthly (an business issue) so I`m note able to load it in small requests every day.
To make the things worse I have that start routine to carry on Balance (sapnote_0000577644 - DataSource 0EC_PCA_3 and FI-SL line item DataSources).
It`s not taking the package size of the infopackage in consideration (1000 Kbs / 2 processes / 10 pkgs/IDoc Info).
Config:
- BI 7.0 SP 23/AIX/Oracle
- ECC: AIX/Oracle PI_BASIS 2008_1_700 000 / SAP_ABA 700 015 / SAP_BASIS 700 015 / SAP_APPL 600 013
I checked sap note sapnote_0000917737 - Reducing the request size for totals record DataSources but it not apply to us...
Someone have any idea how to fix it?
Thanks in advance,
Alex

Chubbyd4d wrote:
Hi masters,
I have a package of 11,000 rows coding with around 70 procedures and function in my DB.
I used array to handle the global data, and almost every procedure and function in the package using the array.
The package was creating problem in debugging. Gave me the Program too large error. so it came to an idea to split the package to smaller packages.
However, the problem that I would like to discuss are
what is the advantage to split the package into few smaller packages. How is the impact on the memory.
if I chunk the package into few packages, will it be easier if use GTT instead of array for the global data? How is the impact on the peroformance, since GTT is using I/OOne of our larger packages is over 20,000 lines and around 500 procedures on a 10.2 database.
No problem or complaints about it being too large.
As for splitting packages, that's entirely up to you. Packages are designed to put all related functionality in one place. If you feel a need to split it out to seperate packages then perhaps consider grouping together related functionality on a smaller granularity that you previously had.
In relation to memory, smaller packages will take up less space obviously, but if you are going to be calling all the packages anyway then they'll all get loaded into memory and still take up about the same amount of memory (give or take a little).
GTT's are generally a better idea than arrays if you are dealing with large amounts of data or you need to run queries against that data. If you need to effectively query against the data then you'll probably end up with worse performance processing an array in a query style than the IO overhead of a GTT. Of course you have to look at the individual processes and weigh up the pros and cons for each.

Program too large

Similar Messages

Maybe you are looking for