Dynamics 365 Business Central: RecordRef and the new SetTable parameter on v22

The RecordRef variable type is historically used in Microsoft Dynamics NAV and Dynamics 365 Business Central to work with a record object when you don’t necessarily know which record you’re handling (the RecordRef object can refer to any table in the database.).

RecordRef object has lots of methods that you can see listed and explained here.

In this poist I want to mention these two methods:

• RecordRef.GetTable is used to point a RecordRef at the same table instance as a Record variable
• RecordRef.SetTable is used to point a Record variable at the same table instance as a RecordRef variable.

These two methods are sometimes useful to transfer data between a RecordRef and a normal Record variable.

What’s new in version 22?

The new version 22 (runtime 11) introduces an hidden new feature related to the RecordRef.SetTable method. Previously, the SetTable method had this signature:

RecordRef.SetTable(Rec: Record)

Starting from runtime 11, you have also this new signature (overload):

RecordRef.SetTable(Rec: Record, ShareTable: Boolean)

The new ShareTable parameter specifies whether the method copies filters, views, automatically calculated FlowFields, marks, fields, and keys of the record or creates a reference to a temporary record. If RecordRef and Record are both temporary and ShareTable is true, then the COPY method causes Record to reference the same table as RecordRef. If ShareTable is true, then both Record and RecordRef must be temporary; otherwise an error will occur. If you specify false, only filters, marks, and keys are copied.

To give you an example, consider the following code:

The code creates a temporary RecordRef variable pointing to the Customer table, then it creates 10 temporary Customer records on it.

After that, I use two calls to the RecordRef.SetTable method to point a Record variable at the same table instance as a RecordRef variable. The first call has the ShareTable parameter to TRUE, the second call has the ShareTable parameter to FALSE.

If you test this code, the first call returns 10 records, the second call return 0 records.

A new hidden behaviour to keep in mind and that can be useful on some scenarios…

This post was originally published on this site