Why I got DATA_BUFFER_EXCEED when calling RFC_READ_TABLE to CDPOS in java – Java – Community

The requirement in my java/groovy program is like this: Users are allowed to input table names and table fields as a query input parameters and expect to get some the query result from SAP. From the user input, I get the table name [CDPOS] and [CDHDR]. After reading the SAP documentations and googling, I found these are tables storing change document logs. But I did not find any remote call functions that can be used in java to perform this kind of queries. Then I used the deprecated RFC, "RFC_READ_TABLE" and tried to build up customized queries only depending on this RFC. However, I found if the number of desired fields I passed to this RFC are more than 2, I always got the DATA_BUFFER_EXCEED error even if I limit the max rows.

I am not authorized to be an ABAP developer in the sap system and can not add any FM to existing systems, so I can only write code to accomplish this requirement in JAVA.

Am I doing something wrong? Could you give me some hints on that issue?

19/07/2021 12:36 pm

DATA_BUFFER_EXCEEDED only happens if the total width of the fields you want to read exceeds thewidthof the DATA parameter, which may vary depending on the SAP release - 512 characters for current systems. It has nothing to do with the number ofrows, but the size of a single dataset. So the question is: What are the contents of the FIELDS parameter? If it's empty, this means "read all fields." CDHDR is 192 characters in width, so I'd assume that the problem is CDPOS which is 774 characters wide. The main issue would be the fields VALUE_OLD and VALUE_NEW, both 245 Characters. Even if you don't get developer access, you should prod someone to get read-only dictionary access to be able to examine the structures in detail.

无耻的插头:RCERcontains a wrapper class for RFC_READ_TABLE that takes care of field handling and ensures that the total width of the selected fields is below the limit imposed by the function module.

Also be aware that these tables can be HUGE in production environments - think billions of entries. You can easily bring your database to a grinding halt by performing excessive read operations on these tables.