Partial records 'just' landed, and with that we can pass a list of field IDs to `RecordRef.SetLoadFields()` in order to dynamically load fields while also ensuring we don't pull out columns we don't care about.
Now would be a great time to add the long-missing equivalent for FlowFields, i.e. `RecordRef.SetAutoCalcFields()`. This would let us avoid having to do two SQL calls, one for the initial `Get()`/`FindFirst()` and one to actually bring over the FlowField, which is wasteful (especially if, presumably, it needsa separate CalcField() call for each field!!)
This seems to be an omission and would be good to bring up to parity between normal and flow fields. Thanks!
Comments
I also completely agree that we need this in Business Central. Not being able to use this is causing some performance issues when trying to use more generic code.
Eg. if you loop through 100 records and per record we need to calculate 2 flow fields, we need to do an additional 200 calls.
We can only call CalcField now on a FieldRef, so this is always on a single field (instead of Record.CalcFields that supports multiple fields).
If we could use AutoCalcFields here, we can reduce the amount of calls drastically and will dramatically increase performance.
So, besides adding AutoCalcFields as stated before, I would also like to see a CalcFields on RecordRef that supports multiple fields, to keep all functions between Record and RecordRef/FieldRef in line, where AutoCalcFields is the most important one.
Category: Development
I should've included, we would also need an AddAutoCalcFields() as part of this, just as partial records also have AddLoadFields() on Record and RecordRef.
Since that will affect Records too, not just RecordRef, I'm not sure if MS will want a second Idea for it, but time will tell... ;-)
Category: Development
I am in favor of this request as well. It would be great to extend the functionality.
Category: Development
Thanks Wayne.
> I should also point out that the parameters for a RecordRef.SetAutoCalcFields() would need to be FieldRef instead of Field.
I expect that they will be Integer field IDs, as they are to SetLoadFields(). I don't see why they need to be FieldRefs, and requiring the latter would make for far messier code.
> Or, better yet, add a way to specify 'all' fields :).
Tempting, but potentially dangerous - if someone says 'all' at a time when the number of FlowFields is manageable, but later someone adds a pile of other FFs to the table, so now the first person's code is calculating a load more stuff and slowed down.
Category: Development
Completely agree with this request - was excited when I learned about Record.SetAutoCalcFields()... only to be disappointed when I found I couldn't use it with a RecordRef for more dynamic use cases. This might be obvious, but I should also point out that the parameters for a RecordRef.SetAutoCalcFields() would need to be FieldRef instead of Field. Or, better yet, add a way to specify 'all' fields :).
Category: Development
Business Central Team (administrator)
Thank you for this suggestion! Currently this is not on our roadmap. We are tracking this idea and if it gathers more votes and comments we will consider it in the future. Best regards, Business Central Team