RecId vs SystemId
Hello reader, today I want to talk to you about the differences between two “objects” that we find in AL and therefore in Business Central: RecId and SystemId. Apparently they could have a similar use, but we will see that they are not usable indiscriminately in all scenarios.
RecId is the oldest object and uniquely identifies a record in a table. Historically, it has always been used to link records in generic scenarios, such as in the “Record Link” table where notes and URLs to records in a given table were stored. We often encounter this if you use statements with RecordRef and FieldRef. This is very useful for doing GET on the RecordRef object, completely generalizing a statement.
SystemId is, on the other hand, relatively newer than RecId, as it was introduced starting with Business Central 2019 wave 2. It is a GUID identifier, so it is also a unique identifier that cannot be changed for all records. Once set, the SystemId cannot be changed. Unlike RecId, it is unique for each table, but not for the entire database; therefore we will have a single SystemId for the same table, but the same value may be present in different tables. Also remember that the SystemId, at the moment, is not available for virtual tables. To access its value, you can call the GetBySystemId function.
You may be wondering: but then what is the difference between one and the other since both represent a unique identifier of the record of a table? The biggest difference is that if you rename a record, RecId changes while SystemId does not. This is not trivial, especially if you develop applications that have tables with strong integration with each other. Let’s look at it with an example: I developed three tables (and three list pages). Table 1, the main one, consists of code and description. Table 2 has the RecId of Table 1 and a code as its key, while Table 3 has the SystemId of Table 1 and a code as its key.
Then, on the main page, I created functions to call the other pages by setting a global variable of RecId or SystemId.
Let’s now see the final result of this development.
Here’s what happens if I rename the first record in the main table.
While the page with the source SystemId in key has remained intact.
Another detail I give you about SystemId, reading on the forums, is that if you do Rec1 := Rec2 or Rec1.COPY(Rec2), if Rec2 is saved on the database, it causes a duplicate SystemId error . To work around this problem, use TRANSFERFIELDS cols second parameter to FALSE, or reassign Systemid after copying before saving it because you can still create it manually.
Understanding the differences between RecId and SystemId is critical to using Business Central efficiently. While the RecId is perfect for internal records management, but with the foresight to regenerate references if the main record is renamed; SystemId shines in integrations and data migrations. Choosing the right identifier for the right context can make a big difference in data management and system integrity.
I hope this article has been helpful for your future implementations in Business Central.
