Matthew

So far it does, but I've not submitted it to regular unit testing (edge cases, etc.). I only need it to support an existing workflow with limited functional use (basically I use Access as a UI to make manual DML changes to other underlying databases, the structures of which are not too complicated).

Hopefully the following will be of use for future visitors, it turns out I was using the Number data type, sub-specifying the 'Long Integer' form for the field size (when defining a field in MS Access). Turns out the correct data type to use is 'Large Number' instead of Number.

Looks like that was the issue (and resolved my problem with UCanAccess). Seems I was using the 'Number' type (and sub-specifying 'Long Integer' for 'Field Size'). Changing 'Number' to 'Large Number' fixed it (now my DB is VERSION_16). Thank you for this, at last I can move off Java 7 and the ODBC / JDBC bridge.

Interesting, despite creating a new database with the current version of MS Access (at least it says this; 16.0.13801.20288), when I debug the JetFormat::getFormat method, am seeing VERSION_12 is being returned. I see no option to specify other properties (eg. uncheck a backwards compatibility box or similar)

This is following up from a thread here; https://sourceforge.net/p/ucanaccess/discussion/help/thread/e724c7235e/. If I need to use long (Long Integer) fields in UCanAccess, where do changes (if any) need to be made?

Am making some headway having updated the attached. However, somewhere an int is getting into the mix as when storing Integer.MAX_VALUE + 1, am getting a negative value in the Access field (2's compliment or something).

Line 90 may be the issue (in addition to or instead of the above)... JACKCESS_TO_HSQLDB_TYPES_MAP.put(DataType.LONG, "INTEGER");

The issue appears to be here; net.ucanaccess.converters.TypesMap, specifically this... ACCESS_TO_HSQL_TYPES_MAP.put(AccessType.LONG.name(), "INTEGER"); ...on line 54 (version 5.0.1). Why is a long being mapped to an integer?