Hi @wouter.goslinga 

Try to restart the server you experience this on, or perhaps just the various ODX Services and make sure all TX is not running.

@Thomas Lind restarted the entire VM to be sure, but that did not help. error is the same

Hi @wouter.goslinga 

Try to remove the CSV data source from the ODX by deleting it in TX and in the instance mapping.

Then go to this folder.

Delete the CSV folder and its content. 

Then map the CSV data source again and see that it is recreated there.

When this is done do another restart and see if this have resolved the issue.

@wouter.goslinga: Can you please try Provider Version 23.0.8669

@Thomas Lind I removed the CSV folder and cloned the erroneous datasource. The CSV directory reappeared. But still the same error, also in the cloned datasource.

@AvanWijnen how can I select a specific provider version in the portal?

@wouter.goslinga: By adding a new data source you can select the version: 

@AvanWijnen okay, now we're getting somewhere . The new datasource with the 8669 version does work. So how can I change the version of the erroneous datasource. Using a new datasource would require me to remap all the tables...

We have uploaded the newest version 23.0.8770.0. Try that and see if it works for that.

Also it is not a general thing that the 23.0.8749.0 release gives this error, I have seen many, including myself, use this release with no issuses.

We have just implemented the solution which @AvanWijnen mentioned. The result is that some datasources succesfully complete a full transfer and some still give the exact same error @wouter.goslinga mentioned at the beginning of this post.

See the attached screenshot. 

Datasource in the TX portal is .8669.0

Could someone please assist. Thanks in advance. 

Hi @Tim 
Did you try the 23.0.8770.0?

It works for some and not for others. What differentiates these?

Hello @Thomas Lind ,

Thank you for your reply and help! 

A quick look shows these differences:

• 1. Aggregation of CSV files. 2. No aggregation
• 1. Rowscan depth 1000 2. Normal row scan depth of 100

The datasource with the aggregation is the one that works. 

Hi @Tim 

So doing aggregation works, but not doing so gives this error.

If not, I would like to know which one you get.

Also if you can try the old 8669 version, does both still work then?

My collegeau just created a new csv datasource and created new .RSD files. 

Apparently the old .RSD files did not work with the newer datasources. 

New RSD files add the following code to the .RSD

  <api:script method="GET">
    <api:call op="csvproviderGet">
      <api:push/>
    </api:call>
  </api:script>

  <api:script method="POST">
    <api:call op="csvproviderAdd">
      <api:push/>
    </api:call>
  </api:script>

  <api:script method="MERGE">
    <api:call op="csvproviderMerge">
      <api:push/>
    </api:call>
  </api:script>

  <api:script method="DELETE">
    <api:call op="csvproviderDelete">
      <api:push/>
    </api:call>
  </api:script>
</api:script>

Old RSD only contain

  <api:script method="GET">
    <api:call op="csvproviderCSVOPTIONSWRAPPER">
      <api:push/>
    </api:call>
  </api:script>
</api:script>

If a CSV datasource receives an update is there a way to auto update .RSD files?

Thanks in advance.