Recurring recoverable error: Failed to get table (null).attrep_changes

[JacobTews]

While this is a recoverable error, I am unsatisfied with my Replicate task error log having all those orange triangles and red circles!

Here's the error message, which appears every day or two, basically every weekday:

Failed to get table (null).attrep_changes08CAE00DF6725797
Stream component 'st_0_MWCDC_007' terminated
Stream component failed at subtask 0, component st_0_MWCDC_007
Error executing data handler
Endpoint is disconnected
Failed to handle special table (497) event
Failed to start bulk apply transaction
Failed to execute update statement, stream position is (null)
RetCode: SQL_ERROR SqlState: 08S01 NativeError: 0 Message: [Microsoft][ODBC Driver 17 for SQL Server]Communication link failure

I'm replicating from an on-prem DB2 source to an on-prem SQL Server target.

I suspect there's a task design setting that I can adjust to deal with this (something timing, perhaps?), but I'm not sure what direction to go, and we don't have a dev environment where I can safely experiment and break stuff...

Qlik Replicate 

[Dana_Baldwin · Accepted solution]

Hi @JacobTews 

Looks like the issue is between Replicate and the target based on the error stack. You can try increasing the timeout parameters on the target, advanced tab, internal parameters option.

In the window that opens, put an exclamation point in the search parameter box and scroll down to select the 3 timeout parameters:

cdcTimeout, default 600 seconds

executeTimeout, default 60 seconds

loadTimeout, default 1200 seconds

You could also type in the names directly but they're case sensitive, so using "!" and scrolling to them might be more convenient.

Try with values 3x to 4x the defaults. You may need to adjust further. Please note - endpoint settings such as this will not take effect until the tasks that use them are stopped and resumed - endpoints are only "read" upon task startup.

You'll notice a lot of parameters in this list. We advise not to use them unless Support advises you to. The timeout parameters are safe to adjust.

You may also want to check things on your network and/or target to see if there is a root cause you can resolve, as increasing the timeout values is more of a work around IMHO.

Hope this helps,

Dana

[JacobTews]

Thanks, @Dana_Baldwin! I've adjusted those parameters, and I'll see if I continue getting the timeout error. Next time I run into our systems admin, I'll pick his brain about the communication failures noted in the logs.

[SushilKumar]

Hello team,

If our response has been helpful, please consider clicking "Accept as Solution". This will assist other users in easily finding the answer.

Regards,

Sushil Kumar