Skip to main content
To homepage To homepage
Question

Tables not found in ODX

  • August 25, 2026
  • 2 replies
  • 59 views
Problem Solver
  • RLB
  • Problem Solver

I'm using (legacy) TimeXtender version 20.10.82 with ODX.

I messed up something in the .RSD file for a CData REST data source and subsequently fixed my mistake. But still, somehow, this has broken all tables in that data source. Executing the DSA tells me "Table not found in the data source" while the tables are clearly still there.

I tried executing the synchonize task in the ODX and even deleted the .parquet files and fully loaded everything again. No luck.
 
After "Synchonize objects" in my TimeXtender project all DSA tables lose their mappings to the ODX tables.

TimeXtender probably tries to find the ODX tables but their id's have changed or whatever. Is there a way to fix this without remapping all my DSA tables?

I'm 100% certain I've seen this behaviour before but on a smaller scale with less impact.

2 replies

Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Thomas Lind
  • Community Manager
  • August 27, 2026

Hi ​@RLB 

What generally causes this is running the synchronize task.

A simple way to experience this in any data source, is to locate a selected table, make sure you uncheck it, synchronize so it isn’t found and finally add it again. Now, even though it is the same name and everything, it will be seen as a new table.

What happens on the next execution of a transfer task is that you will get an warning about an item with the same ID existing. So your only way to resolve it is to remove the folder/table, as you also did. Then it can be added again, but is now seen as a completely new table. This will then affect what you mapped to your data warehouse and force you to remap the table there as well.

The only way to avoid this, is to only run the synchronize task when you change the name of the RSD file or any of the fields in there. Though the field names is less of an issue as it will not loose the mapping, only for the specific field.

That is the only changes you can do to a RSD file that requires a synchronization. Any change other than that, like pagination or other advanced features, doesn’t require you to synchronize, as long as the changes are saved in the file it will run the new version without you having to synchronize.

Problem Solver
  • RLB
  • Author
  • Problem Solver
  • August 27, 2026

Correct.

The issue is that everything breaks if you have an error in your RSD and then do a synchronize, which removes all tables in the data source. All other tables are then interpreted as being new, even though nothing has changed really. 

I still think the software should be able to understand that they are not “new” tables.

I'm fixing this for the last time now because we're moving away to a different solution.

Terms and ConditionsAccessibility statement