Error Parsing MASTER FILE APPLICATION_CSV(FOC553) A COMPUTATIONAL EXPRESSION IS TOO LARGE(553)).

Previously my code was working fine suddenly i got this error.
Can u suggest me what to do??

This message has been edited. Last edited by: Kerry,

Post your CODE!

Put in some debugging codes like SET &ECHO=ALL

Are you using a CVS file, Has any of the data length changed? have any new columns been added? If you are not sure then create a second copy of the master file using the creste synonym on the new file and then compare the masters.

Hope this helps

Here goes the code :-

ENGINE SQLORA SET DEFAULT_CONNECTION WINDOWTEST
ENGINE SQLORA
EX STADBGING.WIN_pyths_apwaqep_rpt_pk.WIN_pyths_apwaqep_rpt_sp '','BPL';
-* Two input parameters for the procedure
TABLE FILE SQLOUT
PRINT
*
ON TABLE HOLD AS HEADRPT FORMAT ALPHA
?FF
END
-*-IF &RECORDS EQ 0 THEN GOTO NORECORDS;
TABLE FILE HEADRPT
PRINT
Type
Part_Number AS 'Part Number'
Priority
Part_Type_Reason_for_PPAP AS 'Part Type Reason For PPAP'
Part_Description AS 'Part Description'
Drawing_Release_Actual_Date AS 'Drawing Release Actual Date'
Region
Product_Line AS 'Product Line'
Commodity
Program
Assembly
Assembly_Name AS 'Assembly Name'
Plant_s_ AS Plants
Customer_SOP AS 'Customer SOP'
ABC_SOP AS 'ABC SOP'
ABC_PPAP_Build_Date AS 'ABC PPAP Build Date'
Supplier_Code AS 'Supplier Code'
Supplier
Mfg_Country AS 'Mfg Country'
Mfg__Feasibility AS 'Mfg Feasibility'
Capacity_Verification AS 'Capacity Verification'
SDE
Delegated_SDE AS 'Delegated SDE'
Status
Lead_Time AS 'Lead Time'
PPAP_Required_Date AS 'PPAP Required Date'
PPAP_Commit_Date AS 'PPAP Commit Date'
PPAP_Approval_Date AS 'PPAP Approval Date'
Tooling_PO_Required_Date AS 'Tooling PO Required Date'
Design_Review_Commit_Date AS 'Design Review Commit Date'
Design_Review_Complete_Date AS 'Design Review Complete Date'
LLLRRRA_Commit_Date AS 'LLLRRRA Commit Date'
LLLRRRA_Complete_Date AS 'LLLRRRA Complete Date'
PPMMCM_Commit_Date AS 'PPPCM Commit Date'
PPMMCM_Complete_Date AS 'PPPCM Complete Date'
Run_at_Rate_Commit_Date AS 'Run at Rate Commit Date'
Run_at_Rate_Complete_Date AS 'Run at Rate Complete Date'
HEADING
"ABC Ltd."
"XYZ Report"
"Type : BPL"
"Oct 3, 2008 <+0> "
FOOTING
""
ON TABLE PCHOLD FORMAT AHTML
ON TABLE SET HTMLCSS ON
ON TABLE SET STYLE *
UNITS=IN,
PAGESIZE='Letter',
LEFTMARGIN=0.250000,
RIGHTMARGIN=0.250000,
TOPMARGIN=0.250000,
BOTTOMMARGIN=0.250000,
SQUEEZE=ON,
ORIENTATION=PORTRAIT,
$
ENDSTYLE
END
-GOTO FINAL
-FINAL
-EXIT
(FOC336) THE SUM OF ALL FIELD LENGTHS EXCEEDS MAXIMUM.
BYPASSING TO END OF COMMAND
(FOC205) THE DESCRIPTION CANNOT BE FOUND FOR FILE NAMED: HEADRPT
BYPASSING TO END OF COMMAND


Can i get a solution????

This message has been edited. Last edited by: Santhu,

quote:

FOC336

You can always go to the advanced search link in the upper right-hand corner of this page, log in then go to the search menu, type in the error message number and you will get more information. This is what I found:

Symptom:
Definition/Clarification of FOC336 error.
Problem:
Getting a FOC336 error when running a report in Report Assistant off a MASTER
FILE that has multiple LONG columns in it defined as A4000.
Solution:
(FOC336) THE SUM OF ALL FIELD LENGTHS EXCEEDS MAXIMUM.
The sum of the lengths of all fields in a structure exceeds the
limit. The default limit is 32,768 bytes. Reduce the number and
size of the fields in the file, or eliminate JOINs and
cross-references if possible.

FOC336 indicates the total length of selected fields exceeds 32,768 -
reduce the total length of all fields below this 32k limit. This
limit is a limit within the FOCUS Internal Matrix.

To check the total length of a MASTER FILE, run:

CHECK FILE master_file_name.

This reflects the total length of all fields.

So try commenting out some of the fields until you can get it to run. Then you'll have to decide how to fix it, for instance eliminating columns, reducing the size of some columns, etc.

Also there is a limit on the number of characters in column titles. I wanted you to be aware of that as you have really long ones.

quote:

EX STAGINGDB.vin_pts_apqp_rpt_pk.vin_pts_apqp_report_sp '','BOM';
-* Two input parameters for the procedure
TABLE FILE SQLOUT
PRINT
*
ON TABLE HOLD AS HEADRPT FORMAT ALPHA
?FF
END

Adding to what Ginny wrote -- the culprit appears to be the result returned (as SQLOUT) by your RPC. (Unfortunately, that means you have no opportunity to run a CHECK FILE on the MFD; it evaporates after the END line.)

The probable cause? Maybe the RPC was changed (adding more columns to the answer set), or perhaps the columns of a data table it draws on changed. -- Check whether that RPC does a "SELECT *".

Whatever the cause, the virtual MFD for SQLOUT is not valid (as per the FOC336 msg). Since the TABLE request failed on syntax, the HOLD AS HEADRPT was skipped, and that accounts for the second message.

This message has been edited. Last edited by: j.gross,

Ginny --

quote:

"FOC336 indicates the total length of selected fields exceeds 32,768 - reduce the total length of all fields below this 32k limit. This limit is a limit within the FOCUS Internal Matrix."

That statement is inaccurate. (IBI's fault, not yours.) The 32K size limit applies to the FILE's data structure, including any JOINs (hence the general advice to remove unneeded JOJNs). The limit apparently reflects the size of Focus's read buffer: all fields of all segents are mapped to positions within the read buffer, and then used to populate the real and defined Focus fields.

So paring down the list of "selected fields" will not help -- Santhu needs to work on the SQL request to return a more limited answer-set.

Do all the rows in your csv file end with a currency symbol? Perhaps your new data does not have that. Just a thought as to something that snagged me a while ago.

i don't have any CSV file at all
the output is captured in SQLOUT. From that i am going to print.

I tend to agree with Jack, The most likely cause is that the SQL stored procedure
is just returning far more columns than is intended.
Not an unusual situation if you try to make them as generic and reusable as possible.

quote:

ON TABLE HOLD AS HEADRPT FORMAT ALPHA

Why format Alpha?

Just say HOLD AS HEADRPT

How many records do you expect?
You seems to create an active report, that has some limitations.

Show us the master file so we can help you better.

Total number of records are 8,000 . i want the output in excel format for that i should use EXL97 function ok. if i am going to print one column also it is throwing me the same problem(FOC336) THE SUM OF ALL FIELD LENGTHS EXCEEDS MAXIMUM.

Santhu,

Look at the stored procedure as has been suggested.

Even if your TABLE FILE SQLOUT only references 1 column which is format A1
you will get this problem if the internal SQLOUT master exceeds the limit.

By putting on traces and looking at the trace file you may well be able to see exactly
how large your master is.
It is memory resident and so will not appear in the edatemp directory
but has to be parsed by the server so should be in the trace.

quote:

0 NUMBER OF ERRORS= 0
NUMBER OF SEGMENTS= 2 ( REAL= 2 VIRTUAL= 0 )
NUMBER OF FIELDS= 39 INDEXES= 0 FILES= 1
TOTAL LENGTH OF ALL FIELDS=31001
(FOC336) THE SUM OF ALL FIELD LENGTHS EXCEEDS MAXIMUM.
BYPASSING TO END OF COMMAND

Can i know the maximum size of the FIELD LENGTHS???
Can we change the limit of field lengths??

This message has been edited. Last edited by: Santhu,

quote:

TOTAL LENGTH OF ALL FIELDS=31001

Read the information that YOU have posted

And if you will not take the advice offered then there is nothing that anyone can do to help you.

As Jack Gross suggested and as I confirmed.
IT IS YOUR SQL stored procedure that is the problem.

At a returned record length of 31001 bytes with other overheads in place you are breaking
the WebFocus Limit

The fact that this 31001 bytes is made up of just 39 fields implies that the stored procedure
is returning numerous variable length columns of 4k each.

Fix the SQL stored procedure to return ONLY those columns that you require.

If you ask for help listen to the advice.
If you are not prepared to listen to the advice do not bother to ask the question.