Skip to main content
To homepage To homepage
Solved

CSV with https URL

  • February 4, 2026
  • 3 replies
  • 54 views
R
Problem Solver
  • RLB
  • Problem Solver

We use the CData provider for CSV to ingest data from a https URL. The source system does not offer any other way to access the data. This works well. TimeXtender Classic with ODX.

We're now looking into migrating away from CData (not trying to start a discussion about the reason...). The TimeXtender CSV provider (version 16.4.23.0) does not suport a https location, only local file/azure/s3/sharepoint/google/sftp/ftps.

 

Is there some way to get this to work? The current workaround is to use the TimeXtender REST provider but that's quite a hassle to set up, especially when there are lots of columns involved. Also, it's really not a REST API with CSV response. It's a regular URL.

Best answer by RLB

I got it to work using the TX REST provider. Configuring it was a bit more work (and not as straightforward) compared to the CData provider for CSV. With that one, all you do is past the complete URL (including 42 GET-parameters) into the URI field and be done with it. The TX REST provider required a bit more config work. But it's fine now.

Thanks.

3 replies

Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Thomas Lind
  • Community Manager
  • February 6, 2026

Hi ​@RLB 

How exactly do you connect to the source? The TX REST provider can have CSV as the data option of a given endpoint.

R
Problem Solver
  • RLB
  • Author
  • Problem Solver
  • Answer
  • February 9, 2026

I got it to work using the TX REST provider. Configuring it was a bit more work (and not as straightforward) compared to the CData provider for CSV. With that one, all you do is past the complete URL (including 42 GET-parameters) into the URI field and be done with it. The TX REST provider required a bit more config work. But it's fine now.

Thanks.

R
Problem Solver
  • RLB
  • Author
  • Problem Solver
  • February 20, 2026

Just a quick follow-up on this topic.

Like I said I got this working with the TimeXtender REST provider. But now we are getting warnings about invalid XML characters. This was never an issue with the CData provider for CSV because there was no XML involved.

The provider is now dropping invalid characters (these are actually emojis like 👍and ❤️) that we need to keep. Don't ask why.

The warning message is not very helpful:

Invalid XML characters found at positions 35804, 35805, 57702, 57703, 57704, 57705, 57706, 57707, 58169, 58170  and 198 places. Data source automatically removed those invalid characters. In case you would like to override this behaviour, configure "Search and replace" to replace these special characters with something else.

It does not tell me what the invalid characters actually are :(

This is very annoying. My currect workaround is manually downloading the (huge) CSV file and manually searching for any weird characters so I can add them to the Search and replace section. Becasuse “position 35804” has no meaning within the CSV this is quite tedious. Ideally I would like to just keep the emojis as they are.

I have tried looking inside the raw XML file that the REST provider creates but the characters seem to be already deleted there so I cannot search for them.

Terms and ConditionsCookie settingsAccessibility statement