MS Access does not have a DateTimeOffset data type so the value should be converted to UTC and saved as a normal date/time
This fixes 2 things
Regression in 7.0 series where the DateTimeOffset was being written as Local time and not UTC.
When reading the value and converting from a DateTime, the Offset value ended up being implicitly set to the systems local time zone offset. A DateTimeOffset from a UTC value should actually have an offset of 0. This has been wrong since the 2.2 series
* Add expression visitor to locate a scalar subquery. Handles finding deeper subqueries better than original code.
Also handle the case where the expression can be regarded as scalar (i.e. has a TOP 1 and projects only one field). In that case we rewrite the projections so that we take out any previously added projections as it is clear we are not needing it higher up in the SQL
* Lift scalar subqueries out of order by and into a projection
* Add back in missed verifier for skip without order by in split query
* [GitHub Actions] Update green tests.
* Scalar expressions within a function or case expression, within the ORDER BY also need to be lifted
* [GitHub Actions] Update green tests.
---------
Co-authored-by: github-actions <github-actions@github.com>
* Update the BuiltInDataTypes set of tests
* Update JetTypeMappingSource.cs
Add back `alphanumeric` as its line somehow got deleted
* Add Element Type Mapping check back in
* Revert pull-in of GearsOfWar related classes.
* Clean-up GearsOfWar fixtures.
* Drop constraint to workaround Jet limitation regarding compound foreign keys and NULL.
* Fix SQL assertions.
* Revert "Add code to add a "MatchSimple" annotation to a foreign key", because it doesn't do anything at the moment.
This reverts commit 76408338e0.
- Don't derive Timespan and DateTimeOffset type mapping from our JetDateTimeTypeMapping. We can derive from the normal base class for those types
- DateTimeOffset is now mapped to a string. This allows us to round-trip all the details, however any calculations or queries for any components do not work
We try to detect this and when visiting the column (but only if we are within a binary expression and not a projection) we quickly wrap it in a convert function to make it properly numeric
The top/outer projection of this field can still be in a non numeric format, but JetDataReader is able to handle that. Would be better to produce the correctly converted data output anyway
Christopher Jolly
Laurents Meyer