Skip to main content

Good Day,

 

Background:  Our current business requires that the Field History Tracking objects be replicated for reporting.  The initial replicate works, but the refresh we have scheduled to run hourly fails as the call to getDeleted returns 600000 or more deleted records - My initial thoughts are that these field tracking objects do not contain a SystemModstamp field and so DBAmp uses the data the table was created vs the last time the Refresh was ran (someone can correct me if I am wrong)

I understand that there is a limitation of objects needing the SystemModstamp field for proper replication / refreshing but has anyone successfully replicated / refreshed (in a reasonable time interval) Field History Tracking objects?

 

Any help would be greatly appreciated.

Hi @kmauzoul 

Indeed, the Field History objects like FieldHistoryArchive for example, do not support filters on the SystemModstamp column, which SF_RefreshAll uses to decide whether to do a full copy or a delta copy of the table. So, you will not be able to include this table in SF_RefreshAll, unfortunately. If it is necessary for you to keep this table refreshed, you should use SF_Replicate to do a full copy of it each time. 

You can use the DBAmpTableOptions table to skip the FieldHistoryArchive in your SF_RefreshAll run. You can find instructions on this in our documentation below:

Using the DBAmpTableOptions table: https://cdn.cdata.com/help/AFH/dbampd/UsingTheDBAmpTableOptionsTable.html 

If this does not answer your question, feel free to reach out to the [email protected] and one of our DBamp support specialists will further assist you.

Reply


Virtual Event: Data Virtualization, Reimagined Ma”arch 14, 2024 style=
Terms and ConditionsCookie settings