August 5, 2014
Journey into Mystery! Working with RecordRef Variables in Dynamics NAV
The RecordRef and FieldRef variable types are used in Microsoft Dynamics NAV to handle working with a record and fields in a record when you don’t necessarily know which record or fields you’ll be handling. In this blog entry, I’ll write about how to work with them. NOTE: These instructions should apply to all versions of Dynamics NAV from version 3.7 up to and including Dynamics NAV 2013 and Dynamics NAV 2013 R2. Writing code around Microsoft Dynamics NAV, you may have seen the RecordRef, FieldRef, and KeyRef variable types. If you’ve never gotten to use them, you probably don’t quite know what they are or how they work. These three variable types are used when you know that you need to work with a record or set of records, but you don’t know exactly which table you’ll need to access. Generally, I’ve used RecordRef variables under two different circumstances. Either I needed to do the same operation with several very similar tables, like Sales Header and Sales Invoice Header and Sales Shipment Header, or I’ve needed to do the same operation on a whole bunch of tables having nothing in common. In either situation, the thing that drove me to RecordRef variables was that I didn’t know which table I’d be dealing with until runtime. (The biggest project I had to do using RecordRef involved synchronizing records between NAV and an external database in real-time via web service calls; I used the OnGlobalInsert, OnGlobalModify, OnGlobalDelete, and OnGlobalRename triggers in the ApplicationManagement codeunit to call some web services along with RecordRef variables to send the data over.) RecordRef is basically a normal Record variable, only requiring that you feed it the table number so that NAV knows which table you want to work with. You do that via the RecordRef.OPEN function, which takes three parameters:
- No. (required): This is the table number that you want to work with. You can use the DATABASE::[table name] option variable to find the number of the table that you’re wanting to use, if you don’t know it ahead of time.
- Temp (optional): This is a boolean telling the system whether you want to open up a temporary table (TRUE) or a real table (FALSE). If you omit this, the system assumes you want a real table.
- CompanyName (optional): This is the NAV company name that you’re working with. If you omit this, the system assumes you’re working with the current company.
OnRun() Cust.GET('10000'); Cust2.GET('10000'); Cust2.Name := 'Changed'; CLEAR(RecRefCust1); RecRefCust1.GETTABLE(Cust); CLEAR(RecRefCust2); RecRefCust2.GETTABLE(Cust2); RecordCompare(RecRefCust1,RecRefCust2); RecordCompare(RecRef1 : RecordRef;RecRef2 : RecordRef) ChangesMade := FALSE; lCounter := 1; REPEAT CLEAR(FldRef1); FldRef1 := RecRef1.FIELDINDEX(lCounter); CLEAR(FldRef2); FldRef2 := RecRef2.FIELDINDEX(lCounter); ChangesMade := (FldRef1.VALUE <> FldRef2.VALUE); lCounter += 1; UNTIL ChangesMade OR (lCounter > RecRef1.FIELDCOUNT); IF ChangesMade THEN BEGIN MESSAGE('The records do not match.'); END ELSE BEGIN MESSAGE('The records are the same.'); END;Subscribe to Tom Hunt blogs, or, for more information on topics related to Microsoft Dynamics NAV development, read the ArcherPoint Developer Blog written specifically for Microsoft Dynamics NAV developers.
- Login Error: Communication protocol mismatch between client and server
- Creating a Date Table in Power BI
- The Top Eight KPIs Retailers Should Be Tracking (with Formulas) for Your Retail KPI Dashboard
- Difference Between IaaS, PaaS, and SaaS And When You Need to Use Them
- The Microsoft Technology Stack – What It Is and Why You Should Care