Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Feb 16, 2022 5:54:52 AM
Feb 8, 2022 6:25:45 PM
There are instances while working with Qlik Replicate that we tend to get busy and don't remember that the tool requires regular maintenance. As per the unspecified recommendation, we should be restarting the Qlik Replicate Window service once a month to keep the tool in healthy condition. If we lag behind on the maintenance schedule then the tool starts behaving weird which tends to cause issues that shouldn't be an issue in the first place. I'll go ahead and discuss one of those issues in the article.
Error as per the log: Metadata Manager table definition cannot be found in the Source. Table ID: 121 [1021802] (metadatamanager.c:1957)
Scenario: There is an existing task which is running fine for both Full Load and CDC and we try to add new tables to the task and it starts throwing this error.
Cause: The team was lagging behind on the maintenance of the Qlik Replicate instance and due to that it could not update the internal metadata with the changes required for the new tables.
Fix: In the Advance Run options for the task we have an option Metadata Only, which in turn has two more options:
In this particular scenario, we have to go with option 2 which will build the data from all newly added tasks and then stop. This will retain all statistics on the earlier existing tables (mentioning full load is carried out earlier and table load is complete) and the newly available tables will be ready for Full Load.
Note: The information in this article is provided as-is and to be used at your own discretion. Depending on the tool(s) used, customization(s), and/or other factors ongoing support on the solution below may not be provided by Qlik Support.
Hi,
In my past experience, the "Recreate all tables and then stop" will cause the timeline of the task to skip to the current moment in time. In regards to change tables and audit table, if there was latency before you stopped the task, and you simply select resume after refreshing the metadata, the task will start processing changes from the time you refreshed the the task metadata and you will likely have missing data.
I'm not sure how this behaves with normal replicated tables, but I assume it should have the same effect since this affects the timeline of the task.
Our solution was to resume the task using a timestamp before the latency or using the 'last source timestamp' from the redo logs.
Regards,
Mohammed