Peter Obel

Launching a Shared Access Application from a Local Copy

What the launcher was probably for

This article is a reconstruction from a small batch launcher and a shortcut script. The original article file was empty. The date above is the surviving scripts’ SVN commit date, not a verified first publication date. The application names and paths below are generic.

The likely goal was to distribute an Access application from one shared location without making everyone open the same front-end file over the network.

Each user would launch a small updater. It would copy the current client into a directory under that user’s application-data folder, then open the local copy. Publishing an updated client to the share would make it available on the next launch, without a separate installation on each workstation.

Here, “remote start” appears to mean starting an application distributed from a remote file share. The scripts do not start a process on another computer.

One shared release, one local copy per user

The setup script supplies a few application-specific values to a reusable launcher. A sanitized version of that configuration looks like this:

@echo off
set "name=Shared Application"
set "root=\\fileserver\applications\shared-app"
set "client=%root%\Client"
set "destination=%APPDATA%\SharedApplication"
set "batfile=%client%\%~nx0%"
set "icon=icon.ico"

call "%~dp0run.bat"

This is only the configuration wrapper, not a complete replacement updater.

The distinction between client and destination is the important part. The share contains the distributable client; the user profile contains a disposable working copy. There is no need for users to write into the release directory, and one user’s local front end is separate from another’s.

What the surviving implementation does

The generic launcher follows this sequence:

  1. Create the local destination directory.
  2. List .adp client files on the share in modification-date order and retain the final filename, apparently intending to select the newest release.
  3. Delete the files directly inside the local destination, then copy the selected client and icon files from the share.
  4. Write a per-user trusted-location registry entry for the local client folder.
  5. Write the shared root path into a local lnk.txt file.
  6. Locate an installed Access executable using a short list of conventional installation paths.
  7. Create or update a desktop shortcut that points back to the shared launcher.
  8. Start Access with the local client file.

The .adp extension identifies a legacy Access project rather than an ordinary file-based database. Such a client would typically connect to a database server, but these scripts do not establish the actual backend configuration.

The lnk.txt file probably let the client discover the shared application root. The launcher only writes the file; no surviving application code here proves how it was consumed.

Why the shortcut points to the launcher

The shortcut helper accepts a display name, target path, and icon path. It uses the user’s desktop folder to create the shortcut, with the shared batch file as its target and the copied local icon as its icon.

That target is deliberate. If the shortcut opened the local client directly, later launches would bypass the update step. Returning to the shared launcher keeps release selection in one place.

The trade-off is dependence on the share: a local client may exist, but this shortcut still requires the shared launcher to be reachable.

Where the original approach is fragile

The mechanism is small, but the original implementation is not a robust updater:

  • It deletes the old local files before checking that the new copy succeeded. A lost connection can leave the user with no usable client.
  • Its filename-selection loop does not preserve names containing spaces. There is also no explicit handling for an empty release directory.
  • It has no release manifest, signature verification, rollback, or check for an already-running client.
  • Executable discovery assumes particular installation directories, including a final fallback that is not checked for existence.
  • The trusted-location entry targets one Access version even though executable discovery considers several versions.

The local destination must therefore be dedicated to replaceable application files, never user documents or the authoritative database. A replacement should stage and validate an update before replacing the working copy, handle failures explicitly, and keep the previous client available for recovery.

Trusting the local folder also makes the release share a security boundary. Only authorized publishers should be able to change the files that users will copy and execute. Broadening trusted locations is not a substitute for that control.

Takeaway

The best reading of these scripts is a lightweight deployment scheme for a shared Access application: publish centrally, copy locally, and always enter through the updater. The useful idea is separating distribution from execution. The destructive replacement step and unchecked assumptions are historical limitations, not recommendations to reproduce unchanged.