Skip to main content
Solved

HTTP 404 error on incremental load with update & delete detection


wouter.goslinga
TimeXtender Xpert
Forum|alt.badge.img+2

I am using ODX version 6143.1. When loading a table from a source system, incremental load on a datetime column (with an offset of 7 days) works fine. But when I set up the incremental load rule with Detect deletes and Detect updates selected, the first incremental load (which is the initial load) runs successful, but a second load (which should be the increment) gives me a 404 HTTP error:

Response status code does not indicate success: 404 (The specified path does not exist.).

 

Edit: problem only arises when setting the Delete detection option. When I remove this checkbox, the 404 error disappears (so the Detect primary key updates option does work correct).

Best answer by Christian Hauggaard

@wouter.goslinga regarding the HTTP error, a fix has now been tested will be made available in the next release

View original
Did this topic help you find an answer to your question?

15 replies

Thomas Lind
Community Manager
Forum|alt.badge.img+5
  • Community Manager
  • 1015 replies
  • February 17, 2023

Hi Wouter

What is the specific Oracle provider you use? It may relate to what provider type it is.


wouter.goslinga
TimeXtender Xpert
Forum|alt.badge.img+2
  • Author
  • TimeXtender Xpert
  • 52 replies
  • February 17, 2023

Hi Thomas, I'm using the OracleClient Data Provider; ODX storage is ADLS gen2


Forum|alt.badge.img+3
  • Contributor
  • 82 replies
  • February 17, 2023

Can you use an Oracle SQL Profiler tool to review what query statements were sent to the source for HTTP 404 error ?

Also, there is a new option for the ADO and OLEDB data sources called "Date and time syntax'

Options are: Default, ANSI, and ODBC.
For Oracle, you will need to set it to ANSI to get the date-time formatting to work.


wouter.goslinga
TimeXtender Xpert
Forum|alt.badge.img+2
  • Author
  • TimeXtender Xpert
  • 52 replies
  • February 20, 2023

@Syed Yousuf not sure how to use an SQL Profiler tool. I have already set the datetime syntax to ANSI (already asked this in a different topic and this was answered by you). Before setting it to ANSI the incremental load did not work at all. After setting it to ANSI, the incremental load does work correctly, but not when checking the delete detection box.

Given the fact that the error is an HTTP error I think the problem lies more on the ODX storage side, because HTTP is of course not used to connect to Oracle, but it is used to connect to the adls gen2 storage container. 


Forum|alt.badge.img+3
  • Contributor
  • 82 replies
  • February 23, 2023

Hi Wouter

You may use an Oracle query Profiler tool to review what query statements were sent to the source which led to HTTP 404 error in ODX processing.  Also examine the folders in ADLS storage.

For additional troubleshooting, you may open a ticket with our support team.


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

Hi @wouter.goslinga did you manage to resolve the error? Would you like to setup a screenshare to investigate further?


wouter.goslinga
TimeXtender Xpert
Forum|alt.badge.img+2

Hi @Christian Hauggaard , no it is not solved yet, setting up a screenshare would be a good idea, i'll send you a DM.


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

Hi @wouter.goslinga thanks for the call. What was the outcome of the test with the TimeXtender Oracle data source? Did you experience the same issue there, or was it only for the OracleClient Data Provider data source?

 


wouter.goslinga
TimeXtender Xpert
Forum|alt.badge.img+2

Hi @Christian Hauggaard ; the TimeXtender Oracle data source fails to synchronize, so I'm unable to check if the problem exists with this provider.


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

@wouter.goslinga what error are you getting for the TimeXtender Oracle data source provider?


wouter.goslinga
TimeXtender Xpert
Forum|alt.badge.img+2

The error when syncing is this one:

The execution failed with error:
System.Data.OracleClient.OracleException (0x80131938): ORA-01555: snapshot too old: rollback segment number 23 with name "_SYSSMU23_3997554902$" too small
 


Forum|alt.badge.img+3
  • Contributor
  • 82 replies
  • March 30, 2023

There is a good discussion on the above error on Oracle forums. 

Here is an example. Does that help ?


wouter.goslinga
TimeXtender Xpert
Forum|alt.badge.img+2

@Syed Yousuf thanks for the link, but it contains a lot of very technical Oracle stuff that I do not understand and to be honest, IMHO it should not be necessary to take a deep dive in to source system database settings or find an Oracle DBA just to be able to sync it in the ODX. Because the source system is managed by its vendor, I have no influence on settings in the source system (or, more specific, the Oracle database), neither do I have any influence on the query that the ODX server runs when synchronizing.

I think it should be the case that if I set up an Oracle connection properly (which I did, the connection shows successful), the sync should work without failing.

The regular Oracle Data Source (the one that gives me the HTTP error which this topic is about) does sync correctly, so it should be possible for the TimeXtender Oracle data source to do this as well. 


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

Hi @wouter.goslinga when I google this Oracle error, the search results suggest that the error may be resolved by retrying the sync task to a time when during server off-peak hours (i.e. it might be a transient issue). 

In terms of the HTTP error for the OracleClient Data Provider data source, I have been able to reproduce this now, and will get back to you on this.

 


Christian Hauggaard
Community Manager
Forum|alt.badge.img+5

@wouter.goslinga regarding the HTTP error, a fix has now been tested will be made available in the next release


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings