Thanks, i didn't even know about this function and since we have a couple tables with millions of records which we are also extending i'm sure we can increase performance in many different places with this. 🥳
if we are loading a flowfield in the setloadfields (Example: Customer.Net Change (LCY)) that is calculated based on a flowfilter (ex: Customer.Date filter) or if the calculation is based on another flowfield, do we need to add the fields (Ex: Date Filter) used in the flow calculation to the setloadfields?Can we use a mix of fields from base app and extension fields in the same setloadfields?
Thanks Erik great video. I've started using this feature since it first came out. I'm thinking of running a SQL profiler in my dev environment to see what the final BC query is that is passed to the DB when loading only extended fields. Just out of curiosity.
The reason for a JIT load on delete is as follows: After the delete has happened, we can no longer do JIT loads, so to enable reading unloaded fields after the delete. cust.SetLoadFields(cust.No); cust.Delete(); message(cust.Name); Above code throws without JIT. Before it would work fine.
SetLoadFields is mainly recommended and useful when you are doing Read. If are doing Insert, Delete or Copy to temporary records, then it's not a very good idea to use it.
![Quando Rondo - Grow Up [Official Music Video]](http://i.ytimg.com/vi/8zFnCg3BO4Q/mqdefault.jpg)
Thanks, i didn't even know about this function and since we have a couple tables with millions of records which we are also extending i'm sure we can increase performance in many different places with this. 🥳
Thank you for this tip , now I update my code to optimize my app.
Did it work?
It would be great if the compiler can read ahead and auto determine the loadfields ..
I was not using it. But as you said- I will use it from now on.
How to get top N records to be displayed in a Page with same source table.
why is Microsoft not using setloadfields on default tables.... ?
Great video as always, how u measured the performence improvement?
i guess you could for example implement this into an API call and just check the response time
Why can't the compiler fill the setloadfields() or an studio extension which checks the code?
Because... events and other things that might get triggered or called dynamically
if we are loading a flowfield in the setloadfields (Example: Customer.Net Change (LCY)) that is calculated based on a flowfilter (ex: Customer.Date filter) or if the calculation is based on another flowfield, do we need to add the fields (Ex: Date Filter) used in the flow calculation to the setloadfields?Can we use a mix of fields from base app and extension fields in the same setloadfields?
Great question, try it out and let me know :)
Thanks Erik great video. I've started using this feature since it first came out. I'm thinking of running a SQL profiler in my dev environment to see what the final BC query is that is passed to the DB when loading only extended fields. Just out of curiosity.
The reason for a JIT load on delete is as follows:
After the delete has happened, we can no longer do JIT loads, so to enable reading unloaded fields after the delete.
cust.SetLoadFields(cust.No);
cust.Delete();
message(cust.Name);
Above code throws without JIT. Before it would work fine.
Thank you Erik
Awesome information Erik
SetLoadFields is mainly recommended and useful when you are doing Read. If are doing Insert, Delete or Copy to temporary records, then it's not a very good idea to use it.
Does anybody know if there Is a performance improvement, if you do a setloadfields on a table without further table extensions?
Depends on record size I would imagine, try it out and let us know :)
There's a mibuso 2022 video that shows this. The bigger the table, and more ext there is, the better the performance gains
It makes me think of Entity framework's lazy loading =)