Deploy the driver to workstations

Every workstation on which Access (or another ODBC application) works through the driver needs it installed – in the bitness of the application. The installation package includes both bitnesses and can be rolled out silently through software distribution or Group Policy. It requires 64-bit Windows; on 32-bit Windows, set up the driver for one user.

On 64-bit Windows, the package Wkl.Data.OData.Odbc-<version>.msi installs per machine:

A 32-bit application loads only the 32-bit driver, a 64-bit application only the 64-bit driver. The package always installs both; which Office a workstation has then doesn't matter.

1. Install the package with administrator rights, interactively or without a window:

   msiexec /i Wkl.Data.OData.Odbc-<version>.msi /qn

   The package requires administrator rights: the Driver Manager looks up a driver name only under HKEY_LOCAL_MACHINE. Without administrator rights, it works only through a user data source, see Only for one user, without administrator rights.

2. If the service uses a certificate from your own certification authority, deploy its root certificate to the same workstations; see The connection fails with 08S01 "UntrustedRoot".
3. If needed, deploy data sources (DSN) without a password, or let users create them in the driver's dialog; see Link a table in Access.
4. Deploy links or data sources for several service roots only with their own DATABASE value each; otherwise Access reads and writes through the wrong connection, without an error message. See Several service roots in one file.

Result: The driver Wkl OData appears in the ODBC Data Source Administrator of both bitnesses.

The installed driver in the 64-bit administrator (German-language Windows); the 32-bit administrator shows the same row.

Where nobody has administrator rights, or the driver belongs to a single application only, it's set up for the signed-in user. The application then reaches it through a user data source, not through the driver name.

1. Copy the DLL in the bitness of Access (x86 or x64 from the package, for example extracted with msiexec /a) to a folder of the user, for example %LOCALAPPDATA%\Wkl\OData ODBC\<version>\x86\Wkl.Data.OData.Odbc.dll.

2. Create a user data source whose only value is the full path of the DLL:

   Key	Value	Content
   HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\<Name>	Driver	full path of the DLL from step 1, without environment variables
   HKEY_CURRENT_USER\Software\ODBC\ODBC.INI\ODBC Data Sources	<Name>	Wkl OData

3. Connect with DSN=<Name> instead of DRIVER={Wkl OData}; all other keywords (URL, DATABASE, sign-in) go into the string as usual, see Driver connection string (reference).

Result: Access links tables through the data source, reopens them, and edits them as with the installed driver.

• One bitness per name: User data sources apply to 32-bit and 64-bit applications at the same time. A data source points to exactly one DLL; create it for the bitness of the installed Access.
• No route without a data source: DRIVER={<path>}, DRIVER=<path>, and a file data source (FILEDSN) fail with IM002 without an entry under HKEY_LOCAL_MACHINE.
• Precedence: If the driver is also installed for the computer, DRIVER={Wkl OData} remains valid. An application can check whether the driver name is registered under HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBCINST.INI\Wkl OData (in the registry view of its bitness), and otherwise use the data source.
• Removal: Delete the data source (both values) and the folder.

• Try one workstation first: Test installation, update, and removal on one workstation in your environment before you deploy the package widely.
• Update: A higher version replaces a lower one, and the package refuses to install an older version over a newer one; data sources and saved sign-ins remain because the package doesn't create them. If a running application has loaded the DLL (for example an open Access), Windows Installer can't replace it; it then names the programs or requires a restart. Close Office before the update.
• Removal: Uninstalling removes the driver and its entry in the driver list. Users' data sources remain and fail with IM002 until a new installation.
• No .NET runtime needed: The driver is a native DLL.
• Manufacturer and signature: The manufacturer is EMSR DATA, D.O.O. (address and contact in the Overview). The list of installed apps and the file properties of the DLL show this; versions up to 0.7.0 still show “The White Knight Labs” there, and an update recognizes them anyway. Application control (AppLocker, WDAC, Smart App Control) checks the DLL when Office loads it. To see whether a version is signed, open the file properties of the package and the DLL (Digital Signatures tab); a signed version names “EMSR DATA, D.O.O.” as the publisher there. Without a signature, application control needs a rule for the path or the hash of the DLL.
• Legal notices: Next to the 64-bit DLL, the package installs THIRD-PARTY-NOTICES.txt (third-party components and their licenses), THIRD-PARTY-NOTICES.dotnet.txt (third-party components of the .NET runtime compiled into the driver), LICENSE.md (license terms of EMSR DATA; the English version is binding), SECURITY.md (reporting a vulnerability, supported versions), and MANUFACTURER.md (manufacturer information, end of support), all three also in German (.de.md) and Slovenian (.sl.md).
• License terms: Installed interactively, the package shows the license terms first and installs only after you accept them. Without windows (/qn, software deployment), no dialog appears; by deploying that way, you accept the terms. Read them beforehand in LICENSE.md.

• Link a table in Access: Prerequisites
• IM002: The driver isn't found