I think the underlying issue of #86 was that the provider is issuing queries against the database using datetime parameters on datetime2 fields, leading to a loss of precision in the queries for both purge and queries scenarii. As sql server datetime is rounding at 0, 0.003, 0.007 seconds, while datetime2 has a precision of 100ns (matching c# DateTime one), this leads to tests failing sometimes, but IMHO, it is also an actual issue in the provider code (even if probably a very small one).
I also made sure a delay of 20ms was left at each point in time capture in tests to ensure they are reliable (to compare with 100ns precision of DateTime/datetime2, ability of the OS to wait for such a low level of time accurately, and 1s which was previously used)
I was able to reproduce the #86 issue in around 20 seconds of running the MultiInstancePurge & MultiInstanceQueries test in a loop on my machine. With this PR code, no failing test has been reported after 2 hours.
I think the underlying issue of #86 was that the provider is issuing queries against the database using
datetimeparameters ondatetime2fields, leading to a loss of precision in the queries for both purge and queries scenarii. As sql serverdatetimeis rounding at 0, 0.003, 0.007 seconds, whiledatetime2has a precision of 100ns (matching c#DateTimeone), this leads to tests failing sometimes, but IMHO, it is also an actual issue in the provider code (even if probably a very small one).I also made sure a delay of 20ms was left at each point in time capture in tests to ensure they are reliable (to compare with 100ns precision of
DateTime/datetime2, ability of the OS to wait for such a low level of time accurately, and 1s which was previously used)I was able to reproduce the #86 issue in around 20 seconds of running the
MultiInstancePurge&MultiInstanceQueriestest in a loop on my machine. With this PR code, no failing test has been reported after 2 hours.