Notifications
Announcements
No record found.
Hi,
when i try to enable change tracking on the composite entity primary table, it says it's not supported.
Is there a way to enable it? if not, is there a similar thing that can be done that detects new changes on the primary table?
Hi JuniorAX,
There are no workarounds for enabling composite entity change tracking.
Do you need to track changes only for the root entity in a composite entity?
If yes, you can implement some kind of status field on the primary table and populate it with "Ready" value when data is inserted or updated in the primary table. During the export, you can update the status with the "Sent" value in postLoad method for the entity. In a data project, you can set up a filter by new status and sent only records with "Ready" value.
Adding to Sergey's comment - you can use such field to "track changes" of the non-primary tables as well. You just need to update the flag on the primary table whenever such changes occur.
Also keep in mind that with this approach any process that reads the entity will set the flag back to false. So if someone uses Excel to read the data, it will reset the flag and your recurring job will not export those records.
Hi Sergie and Nikolaos,
1. Adding code to postLoad to update the status field will affect performance right? it's like adding a virtual field, it will get called for each record exported?
2. I can put range on the entity itself = Ready right? no need for data project
2. I only need to track changes on the primary table and i will put range on entity = Ready, but i didn't get your point Nikolaos. If my postLoad method says the following:
ttsbegin; if(this.Flag == Ready) { select forupdate table where table.Flag == this.Flag; table.Flag = Sent; table.update(); } ttscommit;
why would the status be reseted if someone tries to export it? do you mean it will get back to Ready? or you mean it will be sent and my recurring job will miss it?
3. Is putting ttsbegin and ttscommit will update the flag even if the export failed at the end? if yes, how to solve this?
1. It will impact performance. But not everything that impacts performance is bad. Actually almost everything impacts performance :)
2. Yes. Then you can ONLY query the "Ready" records, no matter if you use data project, Excel, x++ code to query it.
3. If any process reads the entity, postLoad is executed and the flag is set to Sent. And then your recurring job will miss it.
4. You need to use ttsbegin / ttscommit when you update records. Yes, it's theoretically possible that the export fails but your flag is already updated. I'm quite sure that also normal SQL Change tracking would not cover this any better. So I would first wait and see if it causes problem before using much effort in solving it better.
Hi JuniorAX
1. Yes, it will affect performance, but the composite entity uses staging anyway, and the impact of the update should not be dramatic
2. Yes, you can set it on entity level as well and in post-load, you need to use the clustered index key (if you have one) to search for the original record.
3. It's correct, as an alternative you can subscribe to DMFDefinitionGroupExecution.update method and check if status was changed to Finished
[DataEventHandler(tableStr(DMFDefinitionGroupExecution), DataEventType::Updated)] public static void DMFDefinitionGroupExecution_onUpdated(Common sender, DataEventArgs e) { DMFDefinitionGroupExecution dmfDefinitionGroupExecution = sender as DMFDefinitionGroupExecution; MyRootStaging myRootStaging; DMFEntity dmfEntity; if (dmfDefinitionGroupExecution.TargetStatus == DMFBatchJobStatus::Finished) { if (DMFEntity::find(dmfDefinitionGroupExecution.Entity).TargetEntity == 'MyCompositeEntity') { #OCCRetryCount try { ttsbegin; while select MyRootStaging where MyRootStaging.DefinitionGroup == dmfDefinitionGroupExecution.DefinitionGroup && MyRootStaging.ExecutionId == dmfDefinitionGroupExecution.ExecutionId { ... find original record and update it } ttscommit; } catch (Exception::Deadlock) { retry; } catch (Exception::UpdateConflict) { if (appl.ttsLevel() == 0) { if (xSession::currentRetryCount() >= #RetryNum) { throw Exception::UpdateConflictNotRecovered; } else { retry; } } else { throw Exception::UpdateConflict; } } } } }
Hi Nikolaos and Sergie,
Thanks both.
1. You mean i should put the update method in DMFDefinitionGroupExecution.update instead of postLoad?
2. My table is a journal table, so isn't it wrong from a business point of view to add a new field there? if yes, is there another alternative?
1. The result will be the same in both cases. The only difference is that in the update method you can implement mass-update at once, in postLoad, it's one by one
2. You can also implement a log table and add records to be sent into a log table if you don't want to implement new fields for the original table.
Hi Sergie,
where should i fill this log table. After the journal table is filled? or in my entity?
The log table should be filled when the journal table record (or any other related objects) is created\update\deleted (I'm not sure what you want to track).
I think a journal shouldn't be updated or deleted. Instead of delete you can reverse it which will result i think in creating a new one, so basically maybe i should only track the insert
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.
As AI tools become more common, we’re introducing a Responsible AI Use…
We are honored to recognize Neeraj Kumar as our Community Spotlight honoree for…
These are the community rock stars!
Stay up to date on forum activity by subscribing.
Martin Dráb 660 Most Valuable Professional
André Arnaud de Cal... 549 Super User 2025 Season 2
Sohaib Cheema 307 User Group Leader
