Skip to main content
Solved

ODX transfer task results in command timeout

  • 12 June 2024
  • 6 replies
  • 69 views

Hi community,

I have this strange thing I cannot explain. I have a data connection that has been working properly for months. Since the beginning of May the transfer task results in a time out error, where after 1 hour the command time out is reached. I have tried everything to resolve this error; nothing is working. I tried with one really small table and 1 thread (of course setting the time out to a few minutes 😉); same error. 

The strange thing is; I have cloned this exact data connection and tested the transfer task running this exact similar table over 1 thread. This works without any problems. I have also added several other tables, also without any problems I fetch the rows of all tables within a few seconds. 

Does anybody have ANY idea what might cause this extremely weird behaviour? 

6 replies

Userlevel 3

Is the failing table loaded incrementally?

What type of storage are you using? If ADLS Gen2: does deleting the parquet files solve the issue?

Badge

In this transfer task we only fully load the tables. The really small table I tested with contains 8 rows of data and only a few fields. We use ordinary on premise SQL server for data storage.

Userlevel 6
Badge +5

Hi @Remy Kamphuis | Victa which version of TimeXtender are you using?

Badge

Hi @Remy Kamphuis | Victa which version of TimeXtender are you using?

Hi @Christian Hauggaard we are using TimeXtender 6284.1 and same ODX version.

Userlevel 6
Badge +5

Hi @Remy Kamphuis | Victa I have created a support ticket for this

Userlevel 2
Badge +2

@Remy Kamphuis | Victa can you please try to sync the datatypes for the target table with the ODX datatypes (you can do this by right-clicking the top node of the target data area, choose Advanced → Synchronize data types). Make sure the datatypes are exactly the same between the source ODX table and the target data area table.

I have seen this problem multiple times with multiple customers and it always turned out to be a problem with an implicit type cast that does not throw an error but just times out.

Reply