Distribute a Front End to Another Company - Microsoft Access Forum


	Back to Access Forum Comments List

Upload Images @Reply Bookmark Link Email Next Unseen

Distribute a Front End to Another Company

Joseph Bergman

6 months ago

I’ve developed an Access application that runs my company, and recently I’ve had interest from other companies who want to use the software as well. I’m currently in discussions with one of them, and they have some understandable concerns about me having access to their data.

What I’m trying to figure out is the best way to distribute an ACCDE front end without including their SQL Server connection string.

My initial idea is this:
I provide them with the ACCDE front end, and separately they store an Access file (or config file) on their server that contains their connection string. When my front end loads, it would look for that file, read the connection string, and build the connection. I would do the same on my end for my test/development environment.

Before I go too far down that path, I wanted to ask if anyone else has solved this problem or has recommendations for a clean way to handle per-client connection strings in a distributed Access application.

If this is the wrong forum for this question, please let me know where I should post it.

Thanks!

	John Williams @Reply 6 months ago
Richard's link to Mike Wolfe's Week in Review for Access on 11/29 had reference to using .INI toolbox for this information. https://www.linkedin.com/pulse/developer-helpers-ini-file-toolbox-complete-solution-marcus-dieterle-fbnte/

Richard Rost @Reply

6 months ago

Joseph You're right to be careful here, but I wouldn't rely on a password-protected ACCDB for real security. Access passwords are basically light obfuscation and there are plenty of tools that can remove them, so I wouldn't treat that as a safe place to hide a SQL login.

The cleaner approach is to ship a generic ACCDE front end and let the client maintain their own config. On startup, your app reads their settings from an external source they control: an INI file, a small ACCDB with a settings table, or even a registry key. If they can use Windows authentication, that's ideal because you're not storing any SQL username or password at all, just the server and database names.

If they insist on using SQL passwords, then the real security needs to live on the SQL Server side, not in Access. Give them a least-privilege SQL account, restrict what it can do, and accept that anything stored on a user's workstation can be extracted if someone is determined enough. You can lightly encrypt or obfuscate the config file if you want, but that should be considered a speed bump, not a lock.

That keeps you out of their data, gives them full control, and keeps your front end simple and portable.

	Richard Rost @Reply 6 months ago
John INI files are fine for config, but I wouldn't store passwords in them unless they're heavily encrypted.

This thread is now CLOSED. If you wish to comment, start a NEW discussion in Access Forum.

Next Unseen

New Feature: Comment Live View