LAE

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: dhrobertson

Hi,

can someone tell me why sometimes I run the ERPAcquisitionHelper node and sometimes it will error with the following:

Number of rows is not consistent in all returned table extracts. Expected 7370 rows, received 7382.

what can I do to get round this error?

if I run the node again, it generally will work.

thanks

Douglas

Note: This was originally posted by an inactive account. Content was preserved by moving under an admin account.

Originally posted by: Tim Meagher

Hi,

Sorry for the delay in response.

I'm not sure why this error would happen randomly.
I believe what is happening is that the table being retrieved has more than 512 bytes (the maximum of RFC_READ_TABLE).
When this happens, the same function needs to be called multiple times, retrieving some of the fields each call - never more than 512 bytes total.
Rather than calling this once per-record to retrieve, it batches these up to retrieve a batch of table "extracts" for each call.
For instance, if the table had 4 fields, and the first 2 fields where 200 bytes long each, and the second two were also 200 bytes long, and the node options are set to retrieve (for instance) 300 records per batch, then the function will first execute to retrieve the first two fields for the firs 300 records, then the function will be executed to retrieve the second 2 fields for the first 300 records.
The string "data" field returned from RFC_READ_TABLE is then extracted into the individual fields in the table, and converted to the appropriate data type, and the records are then pieced back together from the individual function calls.
From the looks of things, the subsequent calls to extract different fields from the same table using multiple function calls is returning a different number of rows.
I'm not sure what would cause this though - perhaps there is something with caching function results which is causing problems, or perhaps the calls are interfering with each other in some way ....

Figuring this out would take quite a bit of investigation into how the SAP system is reacting to the calls I think.
I wonder if changing the connection method to only use a direct connection and without pooling has any effect (it will certainly slow things down, but maybe leads to more consistent results here)?

Maybe there is something as simple as clearing out some cache on the connections retrieved from the connection pools ... not sure.

Tim.