CC 5.2 Detailed reports too large for Excel

We are upgrading Compliance Calibrator from 4.0 to 5.2. We are required to run several large scans that result in more than the Excel limit of 65,000 lines. CC truncates the reports at the line limit. Has anyone found a way to export these reports in full so we can work with all of the data in MS Access?
Thank you.

If you run the reports in the background you can retreive the raw files by going to the server. The default location is \usr\sap\SID\DVEBMGS<instance number>\j2ee\cluster\server0\virsa\bgJobSpool\ if you haven't specified a different location in the configuration tab.
Files on the server can be identified by Job ID.
The different types of reports are labelled as follows:
[JobID].d.0 = Technical Detail Report
[JobID].s.0 = Summary Report
[JobID].m.0 = Management Summary Report
[JobID].e.0 = Executive Summary Report
[JobID].i = Information about the job
Ways to get the files.
Use an FTP program to connect to the share.
Be sure to transfer files as "text" rather than binary. However, if you are transferring a zipped file, transfer as "binary."
Using SAP GUI (ABAP method)
Log into the ABAP side of your NetWeaver installation.
T-code: AL11 (maybe there are other t-codes that can access the filesystem also)
Browse to the directory on the server: /usr/sap/<SID>/DVEBMGS<instance number>/j2ee/cluster/server0/virsa/bgJobSpool
Use standard SAP GUI functionality to save the file locally, as unconverted text.

Similar Messages

Dimension member listings too large for excel 2003

Hi All,
I have a design issue, using BPC 7.0.112 on SQL 2005, where I want to hold a large number of dimension members which currently exceeds the excel 2003 65,000 row limit. Moving to 2007 is not an option.
Aside from the question, why does the client need to hold so many members, does anyone have any suggestions or previously used solutions to this problem?
In previous software I've used, (Business Objects Planning), my approach would be to detach the front end xls from the backend dimension table. This needed a significant amout of vba code but allowed the application to use the dimension table in the usual way. The downside, however, being that properties and groupings could then not be maintained through the front end.
Has anyone used this approach? Whats the impact on the application?
Many thanks
Phil

Hi,
I have successfully saved/processed a dim workbook with multiple sheets, (using relatively few members on each sheet, 8,000 & 50), however, when now loading some high volumes, 20,000 on each sheet, BPC consistently fails to save the dim member sheet.
"The underlying connection was closed: Could not establish secure channel for SSL/TLS.
Cannot save member sheet to the server; do you want to save it to the local machine?"
I am using a VPN connection to the clients servers so am wondering if this a bandwidth problem? The most I have managed to save and process is about 18,000 members.
Does anyone have any suggestions as what else is causing this failure. Is the reference "could not establish a secure channel for SSL/TLS" pointing at some sort of timeout on the server?
Many thanks

Crystal Reports 9: Page Header plus Page Footer is too large for the page.

Hi,
I have a report that has the following sections.
GH1
GH2a
GH2b - has a sub report
GH2c - has another sub report
GH3
GH4
GH5
details - suppressed
GF5 - suppressed
GF4 - suppressed
GF3 - suppressed
GF2 - suppressed
GF1 - suppressed
The report works fine wehn I run it using Crystal Designer.I am using CR version 9.2.2.693.
When I try to load the report in my application, I get the following error.
Crystal Report Windows Forms Viewer
Page Header plus Page Footer is too large for the page.Error in File rptName.rpt:
Page header or footer longer than a page.
OK
There are no 'suppress blank sections' option set in the sections where the sub-Reports are.
I also tried setting the No Default Printer option.
The report gets loaded from the application only when I set 'New Page after' in the sections where there are sub-Reports.
I do not want to do this; Is there a workaround?
Thank you.

Can someone tell me if this problem is being worked on as it looks as thogh none of the problems regarding the message u2018Page Header plus Page Footer is too large for the pageu2019 have been addressed.
We have several reports that were written in Crystal 7 (I think) and worked in Crystal 9 and X1R2 but now give the above error. We have tried jigging the report in line with the various suggestions but at best can get them to run through successfully with one lot of data and then fail on the second or subsequent pages when you vary the data or report format even slightly. We can report on every bit of data separately or in various combinations but not in others. Changing the bottom page margin by 0.01 cm can cause it to fail on page 7 instead of page 530 (for example). We certainly do not have large page headers (just over 2cm) or page footers (about 0.3cm). We do have some subreports in the details section but have used 'fit to section', added 'keep together', removed u2018keep togetheru2019 from just about everything we can (in desperation) but to no avail. We cannot see a pattern to what is happening. It would be encouraging to know that someone is actually working on this fault.

Page header plus page footer too large for the page in crystal report 2008.

Hi,
when we selecting pieview and print after entering paramter it's showing error: page header plus page footer too large for the page. error in File.rpt page header or page footer loanger than page. and it's not showing print layout format if i connect another printer it's showing layout designe. and some times it's showing letter formate and if i give print it's taking default lamdscape but we setup defual setup for printer 10*12 inches in particular printer.please guide me how we can solve this issues.
regds,
samapth

This is a really hard post to read. See if you can take a bit of time to reword it, but one thing I do understand is that you are getting this error:
page header plus page footer too large for the page.
Typically, you can trust that if the error is thrown, it is true. E.g.; this is not one of those errors that says one thing, and means another. I suspect that you have some field(s) in the header(s) that grow, depending on the data. If there is too much data or the data is too long ( a text for example), the error will be thrown. To resolve this, see if placing the field(s) into a group footer / header will help.
Ludek

Adding virtual column: ORA-12899: value too large for column

I'm using Oracle 11g, Win7 OS, SQL Developer
I'm trying to add virtual column to my test table, but getting ORA-12899: value too large for column error. Below are the details.
Can someone help me in this?
CREATE TABLE test_reg_exp
(col1 VARCHAR2(100));
INSERT INTO test_reg_exp (col1) VALUES ('ABCD_EFGH');
INSERT INTO test_reg_exp (col1) VALUES ('ABCDE_ABC');
INSERT INTO test_reg_exp (col1) VALUES ('WXYZ_ABCD');
INSERT INTO test_reg_exp (col1) VALUES ('ABCDE_PQRS');
INSERT INTO test_reg_exp (col1) VALUES ('ABCD_WXYZ');
ALTER TABLE test_reg_exp
ADD (col2 VARCHAR2(100) GENERATED ALWAYS AS (REGEXP_REPLACE (col1, '^ABCD[A-Z]*_')));
SQL Error: ORA-12899: value too large for column "COL2" (actual: 100, maximum: 400)
12899. 00000 - "value too large for column %s (actual: %s, maximum: %s)"
*Cause:    An attempt was made to insert or update a column with a value
           which is too wide for the width of the destination column.
           The name of the column is given, along with the actual width
           of the value, and the maximum allowed width of the column.
           Note that widths are reported in characters if character length
           semantics are in effect for the column, otherwise widths are
           reported in bytes.
*Action:   Examine the SQL statement for correctness. Check source
           and destination column data types.
           Either make the destination column wider, or use a subset
           of the source column (i.e. use substring).When I try to select, I'm getting correct results:
SELECT col1, (REGEXP_REPLACE (col1, '^ABCD[A-Z]*_'))
FROM test_reg_exp;Thanks.

Yes RP, it working if you give col2 size >=400.
@Northwest - Could you please test the same w/o having a regex clause in col2?
I doubt on the usage of a REGEX in this dynamic col case.
Refer this (might help) -- http://www.oracle-base.com/articles/11g/virtual-columns-11gr1.php
Below snippet from above link.... see if this helps...
>
Notes and restrictions on virtual columns include:
Indexes defined against virtual columns are equivalent to function-based indexes.
Virtual columns can be referenced in the WHERE clause of updates and deletes, but they cannot be manipulated by DML.
Tables containing virtual columns can still be eligible for result caching.
Functions in expressions must be deterministic at the time of table creation, but can subsequently be recompiled and made non-deterministic without invalidating the virtual column. In such cases the following steps must be taken after the function is recompiled:
Constraint on the virtual column must be disabled and re-enabled.
Indexes on the virtual column must be rebuilt.
Materialized views that access the virtual column must be fully refreshed.
The result cache must be flushed if cached queries have accessed the virtual column.
Table statistics must be regathered.
Virtual columns are not supported for index-organized, external, object, cluster, or temporary tables.
The expression used in the virtual column definition has the following restrictions:
It cannot refer to another virtual column by name.
It can only refer to columns defined in the same table.
If it refers to a deterministic user-defined function, it cannot be used as a partitioning key column.
The output of the expression must be a scalar value. It cannot return an Oracle supplied datatype, a user-defined type, or LOB or LONG RAW.
>
Edited by: ranit B on Oct 16, 2012 11:48 PM
Edited by: ranit B on Oct 16, 2012 11:54 PM

ERROR : OpenDoc CR to PDF - File is too large for attachment.

We are getting the following error in 3.1 using an OpenDoc call when we call a large Crystal Report to PDF format...
Error : 52cf6f8f4bbb6d3.pdf File is too large for attachment.
It runs OK from BOE when given parameters that returned 44 pages. (PDF = 139 KB)
We get the error on a parameter-set that returns 174 pages when run via CR Desktop or as a SCHEDULED Instance. (PDF = 446 KB).
Client application can't use the SDKs to SCHEDULE Instances - only configured for OpenDoc calls.....
The BOE server is running on SOLARIS - and it's is a 2 Server CMS-Cluster.
The problem is SPORADIC, so I am thinking the issue is related to a specific setting on one of the servers.
Any thoughts on where to start looking...?

Problem is _not _with the number of Rows returned - it is an issue with the size of the PDF file that it is trying to move.
Found a possible WINDOWS solution on BOB - need to find if there is an equivalent for SOLARIS...
Check the dsws.properties on web server D:\Program Files\Business Objects\Tomcat55\webapps\dswsbobje\WEB-INF\classes
See if you can change any parameter to remove size limitation.
#Security measure to limit total upload file size
maximumUploadFileSize = 10485760

SQL Error: ORA-12899: value too large for column

Hi,
I'm trying to understand the above error. It occurs when we are migrating data from one oracle database to another:
Error report:
SQL Error: ORA-12899: value too large for column "USER_XYZ"."TAB_XYZ"."COL_XYZ" (actual: 10, maximum: 8)
12899. 00000 - "value too large for column %s (actual: %s, maximum: %s)"
*Cause:    An attempt was made to insert or update a column with a value
which is too wide for the width of the destination column.
The name of the column is given, along with the actual width
of the value, and the maximum allowed width of the column.
Note that widths are reported in characters if character length
semantics are in effect for the column, otherwise widths are
reported in bytes.
*Action:   Examine the SQL statement for correctness. Check source
and destination column data types.
Either make the destination column wider, or use a subset
of the source column (i.e. use substring).
The source database runs - Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production
The target database runs - Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
The source and target table are identical and the column definitions are exactly the same. The column we get the error on is of CHAR(8). To migrate the data we use either a dblink or oracle datapump, both result in the same error. The data in the column is a fixed length string of 8 characters.
To resolve the error the column "COL_XYZ" gets widened by:
alter table TAB_XYZ modify (COL_XYZ varchar2(10));
-alter table TAB_XYZ succeeded.
We now move the data from the source into the target table without problem and then run:
select max(length(COL_XYZ)) from TAB_XYZ;
-8
So the maximal string length for this column is 8 characters. To reduce the column width back to its original 8, we then run:
alter table TAB_XYZ modify (COL_XYZ varchar2(8));
-Error report:
SQL Error: ORA-01441: cannot decrease column length because some value is too big
01441. 00000 - "cannot decrease column length because some value is too big"
*Cause:
*Action:
So we leave the column width at 10, but the curious thing is - once we have the data in the target table, we can then truncate the same table at source (ie. get rid of all the data) and move the data back in the original table (with COL_XYZ set at CHAR(8)) - without any issue.
My guess the error has something to do with the storage on the target database, but I would like to understand why. If anybody has an idea or suggestion what to look for - much appreciated.
Cheers.

843217 wrote:
Note that widths are reported in characters if character length
semantics are in effect for the column, otherwise widths are
reported in bytes.You are looking at character lengths vs byte lengths.
The data in the column is a fixed length string of 8 characters.
select max(length(COL_XYZ)) from TAB_XYZ;
-8
So the maximal string length for this column is 8 characters. To reduce the column width back to its original 8, we then run:
alter table TAB_XYZ modify (COL_XYZ varchar2(8));varchar2(8 byte) or varchar2(8 char)?
Use SQL Reference for datatype specification, length function, etc.
For more info, reference {forum:id=50} forum on the topic. And of course, the Globalization support guide.

ReportExportControl -- File is too large for attachment

Hi all,
Back with a exception again.
Few reports deployed on BOXIR2 SP4 comes with an error as following
com.crystaldecisions.report.web.viewer.ReportExportControl
15bf5ea9377e1c1.rtf File is too large for attachment.
Few reports take date range as input and generates result based on that. When date range is small report is generated without any problem. If is large and has large set of records(approx above 10K records) then comes up with the above error.
Another set of reports whatever be the case throws this error.
But when the parameters are set in CMS console and run in console report is generated without any problem what ever be the date range.
After searching a lot no solutions in hand!!
Please suggest solutions/possible scenarios / checklist to solve this issue.
Thanks & Regards
lnarayanan

It turns out the report was so large it was basically overloading everything (disk space, cache sizes, timeouts, etc.) ... Here's the solution from the case:
1) For page server and cache server
Make sure location of Temp Files/Cache files has enough free space (more than 500 MB)
2) For page server and cache server
Minutes Before an Idle Connection is Closed = 90
3) For page server
Minutes Before an Idle Report Job is Closed = 90
4) For cache server
Maximum Simultaneous Processing Threads = automatic
5) In the command line of page server and cache server, add
"-requestTimeout 5400000" [without " "]
6) Maximum Cache Size Allowed (KBytes) = set it to an appropriate value (for e.g. for 500 Mb, value should be 500*1024 = 512000)
(This setting limits the amount of hard disk space used to store cached pages. If we need to handle large reports, a large cache size is needed. Maximum allowed is 2048 GB)
After all this, an "Error 500 - Java heap space" happened. The amount of memory allocated to a JVM application can be set using the options -Xms (the initial size) and -Xmx (the maximum size).
Regards,
Bryan

Fdpstp failed due to ora-12899 value too large for column

Hi All,
User facing this problem while running the concurrent program.
the program is complted but with rhis error.
fdpstp failed due to ora-12899 value too large for column
Can any one tell me the excat solution for this?
RDBMS : 10.2.0.3.0
Oracle Applications : 11.5.10.2

User facing this problem while running the concurrent program.
the program is complted but with rhis error.Is this a seeded or custom concurrent program?
fdpstp failed due to ora-12899 value too large for column
Can any one tell me the excat solution for this?Was this working before? If yes, any changes been done recently?
Can other users run the same concurrent program with no issues?
Please post the contents of the concurrent request log file here.
Please ask your developer to open the file using Reports Builder and compile the report and run it (if possible) with the same parameters.
OERR: ORA-12899 value too large for column %s (actual: %s, maximum: %s) [ID 287754.1]
Thanks,
Hussein

"File is too large for attachment." using the Viewer SDK

Post Author: CBurger
CA Forum: JAVA
I'm using the Viewer SDK to retrieve a report from BOE XI 2 SR2.
This is done via the a piece of Java code ...
ReportExportControl exportControl = new ReportExportControl();
ExportOptions exportOptions = new ExportOptions();
IReportSourceFactory psReportSourceFactory = (IReportSourceFactory) enterpriseSession.getService(ReportConstants.REPORT_PSREPORT_FACTORY);
Object reportSource = psReportSourceFactory.openReportSource(report.getID(), Locale.ENGLISH);
exportControl.setReportSource(reportSource);
exportControl.setURI(reportPath.toString());
exportControl.setExportOptions(exportOptions);
exportControl.setExportAsAttachment(true);
exportOptions.setExportFormatType(exportFormat);
exportControl.setParameterFields(reportParameters);
exportControl.processHttpRequest(request, response, getServlet().getServletConfig().getServletContext(), null);
exportControl.dispose();
The report is generated as an Excel file.
If I call for a small Excel - no problem: a dialog pops up asking me to "save as ..."
If I call for a larger Excel (about 20MB) - PROBLEM "File is too large for attachment."
Unfortunatly I don't find any information in the log files.
Any ideas?

Has this ever been resolved? We are having a similar issue.
Thanks!

Data Profiling - Value too large for column error

I am running a data profile which completes with errors. The error being reported is an ORA 12899 Value too large for column actual (41 maximum 40).
I have checked the actual data in the table and the maximum is only 40 characters.
Any ideas on how to solve this. Even though it completes no actual profile is done on the data due to the error.
OWB version 11.2.0.1
Log file below.
Job     Rows Selected     Rows Inserted     Rows Updated     Rows Deleted     Errors     Warnings     Start Time     Elapsed Time
Profile_1306385940099                                   2011-05-26 14:59:00.0     106
Data profiling operations complete.
Redundant column analysis for objects complete in 0 s.
Redundant column analysis for objects.
Referential analysis for objects complete in 0.405 s.
Referential analysis for objects.
Referential analysis initialization complete in 8.128 s.
Referential analysis initialization.
Data rule analysis for object TABLE_NAME complete in 0 s.
Data rule analysis for object TABLE_NAME
Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.
Functional dependency and unique key discovery for object TABLE_NAME
Domain analysis for object TABLE_NAME complete in 0.858 s.
Domain analysis for object TABLE_NAME
Pattern analysis for object TABLE_NAME complete in 0.202 s.
Pattern analysis for object TABLE_NAME
Aggregation and Data Type analysis for object TABLE_NAME complete in 9.236 s.
Aggregation and Data Type analysis for object TABLE_NAME
Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.
Functional dependency and unique key discovery for object TABLE_NAME
Domain analysis for object TABLE_NAME complete in 0.842 s.
Domain analysis for object TABLE_NAME
Pattern analysis for object TABLE_NAME complete in 0.187 s.
Pattern analysis for object TABLE_NAME
Aggregation and Data Type analysis for object TABLE_NAME complete in 9.501 s.
Aggregation and Data Type analysis for object TABLE_NAME
Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.
Functional dependency and unique key discovery for object TABLE_NAME
Domain analysis for object TABLE_NAME complete in 0.717 s.
Domain analysis for object TABLE_NAME
Pattern analysis for object TABLE_NAME complete in 0.156 s.
Pattern analysis for object TABLE_NAME
Aggregation and Data Type analysis for object TABLE_NAME complete in 9.906 s.
Aggregation and Data Type analysis for object TABLE_NAME
Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.
Functional dependency and unique key discovery for object TABLE_NAME
Domain analysis for object TABLE_NAME complete in 0.827 s.
Domain analysis for object TABLE_NAME
Pattern analysis for object TABLE_NAME complete in 0.187 s.
Pattern analysis for object TABLE_NAME
Aggregation and Data Type analysis for object TABLE_NAME complete in 9.172 s.
Aggregation and Data Type analysis for object TABLE_NAME
Functional dependency and unique key discovery for object TABLE_NAME complete in 0 s.
Functional dependency and unique key discovery for object TABLE_NAME
Domain analysis for object TABLE_NAME complete in 0.889 s.
Domain analysis for object TABLE_NAME
Pattern analysis for object TABLE_NAME complete in 0.202 s.
Pattern analysis for object TABLE_NAME
Aggregation and Data Type analysis for object TABLE_NAME complete in 9.313 s.
Aggregation and Data Type analysis for object TABLE_NAME
Execute data prepare map for object TABLE_NAME complete in 9.267 s.
Execute data prepare map for object TABLE_NAME
Execute data prepare map for object TABLE_NAME complete in 10.187 s.
Execute data prepare map for object TABLE_NAME
Execute data prepare map for object TABLE_NAME complete in 8.019 s.
Execute data prepare map for object TABLE_NAME
Execute data prepare map for object TABLE_NAME complete in 5.507 s.
Execute data prepare map for object TABLE_NAME
Execute data prepare map for object TABLE_NAME complete in 10.857 s.
Execute data prepare map for object TABLE_NAME
Parameters
O82647310CF4D425C8AED9AAE_MAP_ProfileLoader                              1     2011-05-26 14:59:00.0     11
ORA-12899: value too large for column "SCHEMA"."O90239B0C1105447EB6495C903678"."ITEM_NAME_1" (actual: 41, maximum: 40)
Parameters
O68A16A57F2054A13B8761BDC_MAP_ProfileLoader                              1     2011-05-26 14:59:11.0     5
ORA-12899: value too large for column "SCHEMA"."O0D9332A164E649F3B4D05D045521"."ITEM_NAME_1" (actual: 41, maximum: 40)
Parameters
O78AD6B482FC44D8BB7AF8357_MAP_ProfileLoader                              1     2011-05-26 14:59:16.0     9
ORA-12899: value too large for column "SCHEMA"."OBF77A8BA8E6847B8AAE4522F98D6"."ITEM_NAME_2" (actual: 41, maximum: 40)
Parameters
OA79DF482D74847CF8EA05807_MAP_ProfileLoader                              1     2011-05-26 14:59:25.0     10
ORA-12899: value too large for column "SCHEMA"."OB0052CBCA5784DAD935F9FCF2E28"."ITEM_NAME_1" (actual: 41, maximum: 40)
Parameters
OFFE486BBDB884307B668F670_MAP_ProfileLoader                              1     2011-05-26 14:59:35.0     9
ORA-12899: value too large for column "SCHEMA"."O9943284818BB413E867F8DB57A5B"."ITEM_NAME_1" (actual: 42, maximum: 40)
Parameters

Found the answer. It was the database character set for multi byte character sets.

Java.sql.BatchUpdateException: ORA-12899[ value too large for column.......

Hi All,
I am using SOA 11g(11.1.1.3). I am trying to insert data in to a table coming from a file. I have encountered the fallowing error.
Exception occured when binding was invoked.
Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'insert' failed due to: DBWriteInteractionSpec Execute Failed Exception.
*insert failed. Descriptor name: [UploadStgTbl.XXXXStgTbl].*
Caused by java.sql.BatchUpdateException: ORA-12899: value too large for column "XXXX"."XXXX_STG_TBL"."XXXXXX_XXXXX_TYPE" (actual: 20, maximum: 15)
*The invoked JCA adapter raised a resource exception.*
*Please examine the above error message carefully to determine a resolution.*
The data type of the column errored out is VARCHAR2(25). I found related issue in metalink, java.sql.BatchUpdateException (ORA-12899) Reported When DB Adapter Reads a Row From a Table it is Polling For Added Rows [ID 1113215.1].
But the solution seems not applicable in my case...
Can anyone encountered same issue?? Is this a bug? If it is a bug, do we have patch for this bug??
Please help me out...
Thank you all...
Edited by: 806364 on Dec 18, 2010 12:01 PM

It didn't work.
After I changed length of that column of the source datastore (from 15 to 16), ODI created temporary tables (C$ with I$) with larger columns (16 instead of 15) but I got the same error message.
I'm wondering why I have to extend length of source datastore in the source model if there are no values in the source table with a length greather than 15....
Any other idea? Thanks !

EBS - Error F5 263 (Diff is too large for clearing)

Helli Experts,
We are implementing SAP Electronic bank statement functionality. One of the requirements of the business is that of automatic clearing of customer open items after import of MT940.
We are using standard interpretation algorithm 001, but made use of an enhancement to clear the open items based on age of the open items rather than any reference given in Note to Payee details. That means if a customer has 4 overdue open items and paid the amount referring to the 3rd open item, system should rather clear the 1st open item which is overdue for more number of days than the 3rd open item. This has been made possible by activating the check box "Distribute by age" in FEBCL table through the standard enhancement option given by SAP.
As an extension of this requirement, if the customer pays off in lumpsum (in single payment) for the combination of first three open items, then the system should clear off those three open items leaving the fourth one as the open item. For instance first open item has the amount of $ 1000, 2nd one has $2000, 3rd one has $3000 and 4th one has $4000. Now if the customer pays $6000, system should clear the 1st, 2nd and 3rd open items automatically after loading the bank statement containing this payment of $6000. So, only the 4th one will be in open item status.
But when I load the bank statement, system is giving me an error message F5 263 (the difference is too large for clearing) in posting area 2. Posting area 1 is fine and document is successfully posted. Issue is there only in posting area 2. I believe system should be able to find the first three open items for the amount of $6000 based on the indicator of "Distribute by age". But this is not happening. If I try to reprocess the statement through FEBAN after I got this error message, then system is able to find the first three open items and then able to clear off. But wondering why it is not happening in transaction FF.5 automatically.
So, could you kindly let me know if I am missing something or is it a limiation in SAP that this scenario is not possible to achieve through EBS.
Thanks in advance.
Sridhar

Hi Experts,
Using standard BAdI the requirements could be solved. Thanks.
Regards,
Sridhar

Error: (F5 263) The difference is too large for clearing in EBS

Hi
i was running FF_5 , i got the the below error.
Error: (F5 263) The difference is too large for clearing
The next detail screen i found that the Bank account posting gone correct but issues in subledger posting (there 27 errors in the table).
Can i have your inputs on this please.
Thanks for your help in advance.
regards
Raghu

Hello Shanid
You are absolutely correct. There were two line items in my outgoing bank (2 line items of Rs. 4000 each).
In my bank statement (electronic bank statement), there was only 1 line item of Rs.4000). So system gave this error (I checked in FEBAN).
My expectation was, system will read assignment field for the check number and it will consider only one line item of Rs.4000 where check number in bank statement is matching with assignment field.
Please let me know, how to achieve this.
Please note that, this is working fine in manual BRS.
Meena

Update trigger fails with value too large for column error on timestamp

Hello there,
I've got a problem with several update triggers. I've several triggers monitoring a set of tables.
Upon each update the updated data is compared with the current values in the table columns.
If different values are detected the update timestamp is set with the current_timestamp. That
way we have a timestamp that reflects real changes in relevant data. I attached an example for
that kind of trigger below. The triggers on each monitored table only differ in the columns that
are compared.
CREATE OR REPLACE TRIGGER T_ava01_obj_cont
BEFORE UPDATE on ava01_obj_cont
FOR EACH ROW
DECLARE
v_changed boolean := false;
BEGIN
IF NOT v_changed THEN
    v_changed := (:old.cr_adv_id IS NULL AND :new.cr_adv_id IS NOT NULL) OR
                 (:old.cr_adv_id IS NOT NULL AND :new.cr_adv_id IS NULL)OR
                 (:old.cr_adv_id IS NOT NULL AND :new.cr_adv_id IS NOT NULL AND :old.cr_adv_id != :new.cr_adv_id);
END IF;
IF NOT v_changed THEN
    v_changed := (:old.is_euzins_relevant IS NULL AND :new.is_euzins_relevant IS NOT NULL) OR
                 (:old.is_euzins_relevant IS NOT NULL AND :new.is_euzins_relevant IS NULL)OR
                 (:old.is_euzins_relevant IS NOT NULL AND :new.is_euzins_relevant IS NOT NULL AND :old.is_euzins_relevant != :new.is_euzins_relevant);
END IF;
[.. more values being compared ..]
    IF v_changed THEN
    :new.update_ts := current_timestamp;
END IF;
END T_ava01_obj_cont;Really relevant is the statement
:new.update_ts := current_timestamp;So far so good. The problem is, it works the most of time. Only sometimes it fails with the following error:
SQL state [72000]; error code [12899]; ORA-12899: value too large for column "LGT_CLASS_AVALOQ"."AVA01_OBJ_CONT"."UPDATE_TS"
(actual: 28, maximum: 11)
I can't see how the value systimestamp or current_timestamp (I tried both) should be too large for
a column defined as TIMESTAMP(6). We've got tables where more updates occur then elsewhere.
Thats where the most of the errors pop up. Other tables with fewer updates show errors only
sporadicly or even never. I can't see a kind of error pattern. It's like that every 10.000th update
or less failes.
I was desperate enough to try some language dependend transformation like
IF v_changed THEN
    l_update_date := systimestamp || '';
    select value into l_timestamp_format from nls_database_parameters where parameter = 'NLS_TIMESTAMP_TZ_FORMAT';
    :new.update_ts := to_timestamp_tz(l_update_date, l_timestamp_format);
END IF;to be sure the format is right. It didn't change a thing.
We are using Oracle Version 10.2.0.4.0 Production.
Did anyone encounter that kind of behaviour and solve it? I'm now pretty certain that it has to
be an oracle bug. What is the forum's opinion on that? Would you suggest to file a bug report?
Thanks in advance for your help.
Kind regards
Jan

Could you please edit your post and use formatting and tags. This is pretty much unreadable and the forum boogered up some of your code.
Instructions are here: http://forums.oracle.com/forums/help.jspa

CC 5.2 Detailed reports too large for Excel

Similar Messages

Maybe you are looking for