Incremental Data Load Issue

Dear @Kashif ,

These bugs, if it is a bug, is always hard te prove. As I look a look at the first document I could not find the proof of this bug. I did not recalculate though.

To be honest i'm wondering why you use such a incremental rule. When I worked with AX or NAV the MODIFIEDDATE or timestamp is always enough.

Are you 100% sure that these new records fall into the rule?
When I take a look at the second document the AX server is handling a where with 3 rules and an OR. This makes it very hard to really check all possibilities.

What I would do is either: 
- See if I can find hard proof that these records should be loaded with this incremental selection rule

- Check if a ‘simple’ incremental rule gives me the desired results (just a rule on the MODIFIEDDATE)

Take care

= Daniel
 

Hi Daniel, Christian,

Please see response below from the client on this:

1. This is just one example of using "such a rule" to assist in reducing the number of rows. It should work.

2. We are 100% sure that the records are falling into the rule - I have provided all of the evidence in the 2 documents uploaded.

3. Yes, there are 3 statements, one for each of the Companies extracted. They have parentheses which make it quite simple. We are looking at the extract for company 'pick'.

4. I've provided the hard poof in the ticket. The LEDGERTRANS transactions are not being picked up (point 3 in the first uploaded document - TRANSDATE and MODIFIEDDATETIME are 17/08/2023). Yes, they are 'pick' transactions.

5. Yes, the simple incremental rule works. This is what I had originally just based on MODIFIEDDATETIME, however, I need to improve performance with a selection on TRANSDATE, and in other cases, need to use a combination of rules 

6. I provided the dates in the incremental table (point 2 in the first uploaded document), here it is again from the JDM interface:

7. It is quite clear from the settings that I have set in JDM and the subsequent SQL Profiler trace that the incorrect settings are being submitted to SQL, as I pointed out in the second document I uploaded. This is why we believe this is a bug.