Revert "Type MApping: a long gets mapped to integer in Jet"

[lauxjpn]

This reverts commit 05b10ea.

The long datatype in Jet is 32 bit and therefore equals the Int32 CLR type.
We cannot use it to map the Int64 CLR type to Jet.

The decimal datatype in Jet has a total number of 28 digits, which can be used to represent the largest 64 bit value (signed and unsigned) of 18,446,744,073,709,551,616 (20 digits).

So the original implementation should be correct.

[ChrisJollyAU]

The only limitation then is that it will only be supported in OleDb. Odbc still doesn't handle decimal

[lauxjpn]

Good point.

It should also be mentioned, that recent Access database versions have an actual (opt-in) large number data type.

While we could automatically use decimal for OLE DB and integer for ODBC, it would make switching between those underlying providers difficult.

The way to go is probably to add an option that allows users to select between the store types. This way, the large number type can be added later as well.

[ChrisJollyAU]

The large number type for recent version (2016+) might not work. When you enable it it can only be opened by 2016 and later. And then its unknown how it would via OleDb/Odbc as it would need a version of the access driver/provider that can understand that format and data type

By the looks of it quickly one has to enable it directly via the desktop app. Not sure if it can be done programmatically.

[lauxjpn]

Not sure if it can be done programmatically.

Should be possible.

The large number type for recent version (2016+) might not work. When you enable it it can only be opened by 2016 and later. And then its unknown how it would via OleDb/Odbc as it would need a version of the access driver/provider that can understand that format and data type

Yeah, that's why we should make it an option for users to select, rather than a default. If someone enables it, it is that persons responsibility.

Anyway, I don't consider it high priority to implement large numbers, as this is a rather new feature and Jet is mostly a legacy database (except for distributed network share scenarios).

[ChrisJollyAU]

So we go with the option of adding a configuration option to enable using Int64. Call it something like EnableInt64Support

[lauxjpn]

Call it something like EnableInt64Support

It needs to be future-proof in this case here (as discussed above), so it is going to be an enum.

[ChrisJollyAU]

Some comments from a bit of research

1. Saving decimal values with Odbc can be done if configured correctly. The OdbcType field of the parameter needs to be set to Numeric as in ((OdbcParameter)parameter).OdbcType = OdbcType.Numeric . The only drawback is that we would need to include System.Data.Odbc in EFCore.Jet (the main package) rather than it only being pulled in with the .Odbc specific package. Tested with Model79_CantSaveDecimalValue and it passes and round-trips correctly
2. The Large Number data type in Access 2016+ can be used. Obviously if used the database gets stamped and can't be opened by a provider earlier than that (e.g. 2010 database engine).
3. ADOX and DAO do support it and correctly returns adBigInt. We do have a bug there in that the code to convert that to a string returns integer
4. The store types to use in the SQL are bigint and datetime2 (Date/Time Extended is also supported). Using these store types automatically stamps the database
5. Int64 values seem to have a problem being saved (at least in OleDb - havent tested Odbc). It seems x64 gives a conversion error for a parameter (even if the value is just 2). However in x86 it works fine (probably only if the value is within Int32 range, even though parameter has been configured as DbType.Int64). parameter.DbType = System.Data.DbType.Object does the trick. Tested in 365_x64 and successfully round-trip Int64.MaxValue

[lauxjpn]

Nice work!

[ChrisJollyAU]

Once #158 is in this PR should be able to be merged if we want to map Int64/long to use the decimal type as the base/default. Anything else is pretty much under #154

[lauxjpn]

@ChrisJollyAU Hmm, this wasn't finished yet. Is was marked as work-in-progress. Can we revert the merge again?

[ChrisJollyAU]

What was still to do? We had split out the bigint work to #154 . And now that we solved the Odbc bug for decimal we didn't have to have 2 options for the user as to how to treat long. We just default to decimal. They can turn the BigInt support on later if they want

[lauxjpn]

Okay, its fine then.