There was a question by Maddy in the Topic Discussion section about the maximum number of table lines (more than 999) which I would like to answer here. In fact you could assume by the setting for the maximum table lines in the XStep element for a table that this is the limit because you cannot enter more than 3 digits:

However when you look at the characteristic PPPI_MAXIMUM_TABLE_SIZE you’ll see that this characteristic is restricted to 4 digits. If you leave these settings open there is no limitation that I know of. I have made a test with up to 5000 lines in one table (No, I did not add 5000 times a line manually, but I used a function module 😉 ):

I did not try to create more than 9999 lines (the real limit of the characteristic PPPI_MAXIMUM_TABLE_SIZE) because that would have taken too long. And this is probably the restriction which you will encounter even before some technical hard limit – the performance. You have to know that the performance in PI Sheets is not degrading linear with the number of elements you have in that PI Sheet. Especially in tables where you also have a lot of HTML table tags nested together the effect becomes quickly obvious. Here are the results of my little investigation.

In the first series I created a table with only one column (the index that I use to fill the table by the function module) and measured the time it took to load the PI Sheet for a different amount of lines. Up to 2000 lines showed a rather linear rise in time. After this mark it took off in a more exponential way (see red line in diagram below). But one output element is not a very realistic example so I did another series with 10 columns of output fields. Here that point was reached already below 1000 lines and at a much higher level (blue line). Please consider that loading times may differ when you do the same tests in a different environment (e.g. faster/slower server,…), however the principal behaviour should be the same.

Now imagine you also have more complex elements like input fields or even commands or function modules that react on events for every line…

The bottom line is that you need to be very careful about using tables with a lot of lines. Make some extensive tests with real data and check the performance. Maybe it would be a good alternative to capture data in a simple data request and write it to an ABAP database table with a function module if you have a lot of different data sets to store. Even if you need to put this data into an electronic batch record later you could use a custom report there to read the data from that database table and display it in the report that is to be archived later on.