Stream component failed to load

[QLIKPRATHYU]

Stream component 'st_1_SS Prod FanOut' terminated
Stream component failed at subtask 1, component st_1_SS Prod FanOut
Error executing data handler
Endpoint is disconnected
execute statement failed
RetCode: SQL_ERROR SqlState: HYT00 NativeError: 0 Message: [Microsoft][ODBC Driver 17 for SQL Server]Query timeout expired
Failed (retcode -1) to execute statement: 'INSERT INTO [STAGING].[EIDESWTDOC]([MANDT],[SWITCHNUM],[POD],[SWITCHTYPE],[SWTVIEW],[MOVEINDATE],[MOVEOUTDATE],[REALMOVEINDATE],[REALMOVEOUTDATE],[PARTNER],[SERVICE_PROV_OLD],[SERVICE_PROV_NEW],[ENROLLDOC],[DROPDOC],[STATUS],[ERDAT],[ZZ_CONF_REF],[ZZ_MARKET_CODE],[ZZ_SUPPLIER],[ZZ_CSS_REG_ID],[ZZ_MAM_OLD],[ZZ_MAM_NEW]) values (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?)'

[john_wang]

Hello @QLIKPRATHYU ,

Welcome to Qlik Community forum and thanks for reaching out here!

Please try to add an internal parameter to SQL Server target endpoint:

1. Open SQL Server target endpoint
2. Go to the Advanced tab
3. Open Internal Parameters
4. Add a new parameter named executeTimeout 
   
5. set the value to a reasonable value eg 3600 (it's seconds, means 1 hour). You may adjust the value to fit your needs.

Hope this helps.

John.

[Heinvandenheuvel]

>> Endpoint is disconnected
>> execute statement failed
>> Query timeout expired

Most likely Replicate is simply the messenger, carrier the bad new about trouble with the target endpoint connection. Replicate did nothing wrong, the the target had a (network?) problem. Replicate typically disconnected and re-connects to the target, reties the statement and moves on without data loss.

Look very carefully in the REPTASK log around the trouble time. Take good note of the timestamps.

Is this the First time is happnened? Does it frequently? Does it recover?

Wat there a target DB issue, or a network connectivity issue around the problem time?

Can you establish how long the query took? Seconds? Minutes? Typical network timeout delay?

This insert statement should probably take milliseconds only, less than a second, unless the target table was blocked for maintenance perhaps?

If need be, run a few days with LOGGING TARGET_APPLY trace to see how long this query should take.

Hein.