Standard Dynamics 365 for Finance and Operations contains numerous temporary tables that are used by the application and can be used in custom modifications too. Although new temporary tables can also be easily created using the Dynamics 365 for Operations Project, sometimes it is not effective. One of the cases where it is not effective can be when the temporary table is similar to an existing one or exactly the same. The goal of this recipe is to demonstrate an approach for using standard non temporary tables in order to hold temporary data.
As an example, we will use the vendor table to insert and display a couple of temporary records without affecting the actual data.
Carry out the following steps in order to complete this recipe:
- In the Dynamics 365 Project, create a new class named
VendTableTmpwith the following code snippet:
class VendTableTemp
{
public static void main(Args _args)
{
VendTable vendTable;
vendTable.setTmp();
vendTable.AccountNum = '1000';
vendTable.Blocked = CustVendorBlocked::No;
vendTable.Party = 1;
vendTable.doInsert();
vendTable.clear();
vendTable.AccountNum = '1002';
vendTable.Blocked = CustVendorBlocked::All;
vendTable.Party = 2;
vendTable.doInsert();
while select vendTable
{
info(strFmt(
"%1 - %2",
vendTable.AccountNum,
vendTable.Blocked));
}
}
} - Run the class and check the results, which may be similar to this:
The key method in this recipe is setTmp(). This method is available in all the tables, and it makes the current table instance behave as a temporary table in the current scope. Basically, it creates an InMemory temporary table that has the same schema as the original table.
In this recipe, we create a new class and place all the code in its main() method. The reason why we create a class, not a job, is that the main() method can be set to run on the server tier by specifying the server modifier. This will improve the code's performance.
In the code, we first call the setTmp() method on the vendTable table to make it temporary in the scope of this method. This means that any data manipulations will be lost once the execution of this method is over and the actual table content will not be affected.
Next, we insert a couple of test records. Here, we use the doInsert() method to bypass any additional logic, which normally resides in the table's insert() method. We have to keep in mind that even the table becomes temporary; all the code in its insert(), update(), delete(), initValue(), and other methods is still present and we have to make sure that we don't call it unintentionally.
The last thing to do is to check for newly created records by listing the vendTable table. We can see that although the table contains many actual records, only the records that we inserted were displayed in the Infolog window. Additionally, the two records we inserted do not appear in the actual table.