Color scheme: Dark
You are here: start » en » Documentation » Microsoft Access development tools » WKL Forms Object Library » Application and connections » WklLinkManager

WklLinkManager

WklLinkManager keeps the linked ODBC tables of an Access front end in line with a configuration stored in the front end itself, per profile such as DEV, TEST and PROD. The application calls it at start to link its tables to the right sources; developers maintain the configuration in a designer that the add-in WKL Extensions opens from the Access ribbon.

Get started

Common tasks

Visual aid

graph TD
    subgraph FE["Front end (ACCDB / ACCDE)"]
        C["USysConnection – connection rows per profile"]
        T["USysLinkedTable – tables to link"]
        L["Linked tables – tblCustomer, tblOrder …"]
    end
    A["AutoExec: EnsureLinks 'PROD'"] --> M
    D["Database Tools › Add-Ins › WKL Linked Tables Manager (designer)"] --> M
    C --> M["WklLinkManager"]
    T --> M
    M -- "create, repair, relink (DAO)" --> L
    M -- "test, list tables (ODBC)" --> S[("ODBC sources – SQL Server, Wkl OData …")]
    L -. "ODBC" .-> S

Key features

  • Configuration in two local tables: connections in USysConnection, tables in USysLinkedTable; Access hides both in the navigation pane, and they travel with the front end into the ACCDE.
  • Profiles: the same connection name has one row per profile; a row without profile serves every profile. One call switches all tables to another profile.
  • Check before change: Check lists every difference (missing, other source, other remote table, local table in the way, no connection, unmanaged link) without changing anything.
  • Repair at start: EnsureLinks creates missing links and repairs wrong ones; tables that already match are not touched. RelinkAll and Relink link anew on request.
  • Links keep their properties: a new connection is set on the existing link, so descriptions, formats and lookups of the linked table stay.
  • Never destroys data: a local table with a configured name is never replaced; a link that needs to be recreated is first created under a temporary name.
  • Credentials as in Access: Windows login, a stored password or a prompt by the driver, through the connection's parameters. A stored password is clear text in USysConnection and in every link, also in an ACCDE; prefer the Windows login.
  • Without dialogs: connection tests and the list of remote tables never show the login dialog of a driver.
  • Designer with the pages Connections (“Apply to all” for the driver, server, database, and schema), Tables, Profiles, and Check and synchronize; opened from the add-in or with ShowDesigner.
  • Existing front ends: ImportLinks (in the designer, Take over existing) takes the ODBC links a front end already has into the configuration.

Core concepts

The configuration is data of the front end. The tables to link and their sources are rows, not code. A deployment changes rows (or only the profile the application names), never VBA. The fields of both tables are described in the class remarks of the reference.

A connection is a name; the profile picks the row. USysLinkedTable.ConnectionID points to a connection row, but what counts is its Name. For profile TEST the manager uses the row of that name with Environment = TEST, or the row of that name without profile. So adding a profile means adding connection rows, not touching the tables.

Which profile. An operation uses the profile passed as argument, else the Environment property, else the profile the tables are linked with now (DetectEnvironment). When there are profiles and the tables fit none of them clearly, the manager raises an error instead of guessing, so an application never links to production by accident.

Compare, then change only what differs. Every operation first builds the wanted connect string of each enabled table and compares it with the link in the front end. Keywords that drivers or Access add on their own are ignored; a stored password counts. Only differing tables are written, so EnsureLinks at every start costs one comparison.

The designer works on a copy. Edits stay in the window until OK or Apply; then the configuration is checked and written in one transaction. Linking always uses the saved configuration; the Check and synchronize page saves pending edits first.

Runtime. The class works in ACCDB, ACCDE and the Access Runtime. The runtime has no add-ins and no designer menu; applications call the class from their own code there.

Administration

Troubleshooting

For developers

None

en/wiki/msaccess/comctl/application-and-connections/link-manager/start.txt · Last modified: by Wolfgang van der Stille