RFC function to read number of entries

[former_member703104]

Hi,

1. I'm looking for an RFC to get no.of entries in any table/view. "RFC_GET_TABLE_ENTRIES" is working only for tables. If i provide view name as input, it's not working.

Ex: RFC "RFC_GET_TABLE_ENTRIES" works fine with table BSAK in ECC. But in HANA "BSAK" is created as View.

Could anyone suggest correct RFC for this?

2. Also, Is there any RFC available to read no. of entries in a table with WHERE/FILTER condition .

similar to RFC_READ_TABLE. RFC_READ_TABLE doesn't fulfill our requirement as it's actually pulling all the data from the tables.

Thanks

Raj

[michael_piesche · Accepted solution]

Solution 1)

Before looking and searching too long I would build an RFC ZRFC_GET_TABLE_COUNT 😉
And instead of selecting all data, I would directly do a SELECT COUNT (*).
Its a custom solution, but this will also be the fastest solution.

Solution 2)

Even though RFC_READ_TABLE will select all table records for your requirement (in order to count the records), you could still only select one attribute of the table (e.g. the first primary key field) instead of "pulling all the data" (max length is 512). When you receive the DATA parameter, you can count the lines and discard the data.

Solution 3)

You could report an incident and ask SAP to make RFC_GET_TABLE_ENTRIES also work for Views (since it worked before in ECC and you expect it to work in S4 since you didnt change anything but SAP did 😉
They 'just' would have to make their internal system function call 'C_GET_TABLE' also work for views, or provide another call that works for views.

By the way:

RFC_GET_TABLE_ENTRIES also and always pulls all the data of the database table and passes it in the export parameter table 'ENTRIES' where the data will be cut off at length 512. Just because you are not providing the parameter 'ENTRIES' doesnt stop the FM from selecting all the data. The "NUMBER_OF_ENTRIES" parameter is filled by doing a count on the selected data records (and not based on a select count(*) statement). The only advantage you might have, is that the selected table data doesnt get send through the network because the parameter is not provided, but maybe it is and just your local CALL FUNCTION will only discard it when you dont provide the parameter.
Maybe someone with deeper knowledge about RFC parameter provisioning can shed a light on that!

Comparing RFC_READ_TABLE and RFC_GET_TABLE_ENTRIES:

So in terms of pulling data in your special case, RFC_READ_TABLE will very likely be faster than RFC_GET_TABLE_ENTRIES, because with the first RFC you can select only one attribute, whereas with the second RFC will select all attributes. Also RFC_READ_TABLE has more options regarding reading the DDIC as well as setting a WHERE clause.

So especially with big tables, many fetched records but fewer attributes, RFC_READ_TABLE will be faster. With smaller tables, less fetched records or many attributes, the more powerful RFC_READ_TABLE might have too much overhead with DDIC functionalities compared to RFC_GET_TABLE_ENTRIES.

[former_member703104 · Accepted solution]

Thanks Michael.

I can use the solution2 you have proposed.