Table Records Data


I would like to understand how the table records sets the data. Is each row in the a table a pointer to a Record from the Query Record List in the Preparation of the Web Screen?
Or does the plataform make a copy of the Record List to generate and present the data in the Table Record?

I'm asking this because of the 9th best perfomance rule : Avoid using preparation data in screen actions.
So if the table records makes a copy of the data, you can eficiently use it in the screen action, but if its just a pointer, does this mean that even if you use the data from the table I'm still accessing the query from the preparation?

Thanks in advance,

It's a copy, not a reference (pointer).

The problem with using preparation data in your screen actions is related to the page size. This data has to go somewhere, so the viewstate is used, increasing the size of the page.
Thank you very much Paulo!
I spent 30 min learning about the ASP.NET viewstate to understand why the server saves the query results in the view state, so I would like to confirm with you my reasoning:

So in the scenario that a page has a table records loaded with data from a query in the preparation. on the last column there is a button that launches a screen action to display in show records a selected record same page.
1- if I chose the query result from the page instead of the copy created on the page for the button screen action, the server saves the prepartion query results because it detects that the preparation data is being used systematicly in a programmed action on the page. 
2- If I use the copy from the table records, it dosen't save the preparation query cause each button is acessing diferent rows from the html table so there is no need to persist the data in the viewstate.

Does this make sence?

Thanks in advance,
Hi Guilherme,

Yes, that makes sense, and usually it's better to redo the query in the screen action to avoid dependencies from the preparation that would increase the viewstate size.
Note that, if your tablerecord is getting the data from a simple query, there's another optimization that takes place - the actual query statement is tweaked so that only the attributes (table columns) in use by the screen are retrieved (instead of using select entity.*).

Thank you so much (again!) Paulo!

Initially for me it was a bit counter intuitive to redo the query as a better performance option, but then I learned that it has to do with server traffic. Much better to send a Identifier instead of a Record.