Row version change tracking for tables and data entities
Finance and operations apps have a change tracking functionality option that's known as row version change tracking. This option enables Microsoft Dataverse to be used for incremental synchronization of data. Change tracking is a prerequisite for several features, such as Data archival, Synapse integration, Mobile offline, and Relevance search. The eventual goal is to unify all existing finance and operations data synchronization frameworks into one that's based on Dataverse synchronization services.
For row version change tracking functionality, a new column of type, rowversion, must be added to all tables in the data entity that requires change tracking. For more information about the rowversion column type, see rowversion. For information about how to add a rowversion column to a table, see Enable row version change tracking for tables.
The rowversion column performs version stamping of table rows. SQL Server maintains a database-level counter that's incremented for each insert or update operation. Changes to a table row can be detected by comparing the current value in the rowversion column with the previous value.
Enable row version change tracking functionality
Dynamics 365 Finance version 10.0.34 or later requires that you enable the Sql row version change tracking configuration key on the License configuration page (System administration > Setup > Licensing > License configuration). Configuration keys are edited only in maintenance mode. For more information about maintenance mode, see Maintenance mode. When you exit maintenance mode after you enable the Sql row version change tracking configuration key, the database synchronization adds a rowversion column to tables that are enabled for row version change tracking.
Note
The rowversion column is read-only in SQL Server. Therefore, direct SQL Data Manipulation Language (DML) statements that are run by using the X++ Statement object, such as the following example, break if they try to insert or update this column.
INSERT INTO table2
SELECT * FROM table1
Therefore, enable and validate the configuration key in your sandbox environment before you enable it in production. In the unlikely event that direct SQL DML statements try to insert or update the column, you must disable the Sql row version change tracking configuration key until the issue is fixed.
To fix the issue, you must modify the direct SQL DML statement in the X++ code and explicitly specify a column list for source and destination tables, as in the following example.
INSERT INTO table2 (Column1, Column2)
SELECT ColumnA, ColumnB FROM table1
Enable row version change tracking for tables
To enable row version change tracking for a table, set the Allow Row Version Change Tracking property of the table to Yes. The table then gets a new system field of the rowversion type that's named SysRowVersion.
Note
Before version 10.0.34, while row version change tracking functionality was in preview, the row version column was named SysRowVersionNumber. In version 10.0.34, the SysRowVersionNumber column was replaced with a new SysRowVersion column. The SysRowVersionNumber column is now obsolete. In version 10.0.39, it's removed from the metadata of out-of-box tables. Don't make any dependencies for the SysRowVersionNumber column. If your code has a dependency on the older SysRowVersionNumber column, you are required to remove the dependency and test 10.0.39 in your sandbox environment before upgrading your production instance to 10.0.39.
Enable row version change tracking for data entities
To enable row version change tracking for a data entity, set the Allow Row Version Change Tracking property of the data entity to Yes. Not all existing data entities are configured to support row version change tracking. The main limiting factor is the complexity of the data entities. When the Allow Row Version Change Tracking property is set to Yes for a data entity, validation rules are evaluated at build time.
The following table describes the data entity validation rules.
We recommend that independent software vendors (ISVs) and partners always create new data entities when they enable row version change tracking. This approach helps reduce the risk that existing custom extensions violate the validation rules. Validation rule failures from custom extensions are surfaced as build warnings instead of errors to help prevent backward compatibility breaks.
When the Allow Row Version Change Tracking property is set to Yes for a data entity, the SysRowVersion column from underlying data sources is added to the data entity view.
Track deletions and cleanup
Data entity row deletions are tracked by using the AifChangeTrackingDeletedObject table.
A system batch job that's named Delete tracking history clean-up cleans up any records in the AifChangeTrackingDeletedObject table that exceed the retention period. Records are deleted in batches until the time-out criterion is reached. By default, the job runs every day at 1:00 AM. However, you can configure the recurrence and frequency of the job at System Administration > Batch Jobs. Currently, the retention period is 10 days.
Retrieve entity changes
This change tracking feature is fully compatible with Dataverse change tracking. However, there are some differences. For example, changes for finance and operations apps are returned if the last token is within the default value of 10 days, not the value of 90 days that's used for Dataverse tables. For more information, see Use change tracking to synchronize data with external systems.
Váš názor
https://aka.ms/ContentUserFeedback.
Připravujeme: V průběhu roku 2024 budeme postupně vyřazovat problémy z GitHub coby mechanismus zpětné vazby pro obsah a nahrazovat ho novým systémem zpětné vazby. Další informace naleznete v tématu:Odeslat a zobrazit názory pro