Jump to content
EduGeek EdSec 2026 is Go! 27th Oct in Derby! Join us for a day of EdTech security focused talks, networking, and an evening social ×

Where should an installer place writable Access DB file?


Recommended Posts

Posted

Good Day,

I have recently migrated an Access 97 based program to Access 2016. The migration has gone OK, but I am re-creating the installer and I am unsure of location to place files.

 

The program is for managing school sports carnivals. It was previously a commercial package, but the developer consented to it being released as open source if I was willing to upgrade it to work with modern system. https://github.com/ruddj/SportsAdmin

 

The previous installer was designed for Windows 98 and installed everything to Program Files. This will not work in Windows 10 as the Access DB needs to be written to by users. It is a mostly split database, with completely separate user files for each carnival but some config settings are still stored in application DB.

 

I am planning to have two default locations it could install to, for either a system-wide install or a current non-admin user install. The location is just a default and the user installing would be able to modify.

 

The files I need to install are:

  • Access DB file (needs to be writable)
  • Icon
  • CHM Help File
  • Word Documentation
  • HTML & CSS Template files in a subdirectory

Access looks in the same directory as DB file for the icon and help file.

 

Any suggestions on where I should install these? The folder the database is installed to also needs to be writable as Access creates the laccdb locking file. Preferably the folder should also be visible so users can see the Templates easily for editing (e.g. without having to show hidden folders)

 

Is there any system wide location that would meet these? Should I try to separate the files more?

I have been considering ProgramData but that folder is hidden so users would be unable to easily see templates, similar AppData\Local for a user.

I could install the system wide version to a folder in Program Files and modify security rights on the folder, but this introduces security holes, especially for schools that use AppLocker or other restrictions.

 

I was also thinking about installing to “Public Documents” or “My Documents”, but usually you don’t want apps to be installed in Documents folder, especially if using Roaming Profiles.

 

I started working on an installer, but I need to plan out where it should place the files

https://github.com/ruddj/SportsAdmin/blob/master/Source/installs/Setup.nsi

 

Thanks for any ideas or suggestions.

Posted
I have been considering ProgramData but that folder is hidden so users would be unable to easily see templates, similar AppData\Local for a user.

Include both installation paths as options and create a shortcut to the hidden folder on the Start Menu? That's what I would do.

 

Per Machine (Default): %ProgramData%\\

Per User: %LocalAppData%\\

 

I started working on an installer, but I need to plan out where it should place the files

https://github.com/ruddj/SportsAdmin/blob/master/Source/installs/Setup.nsi

 

Have you considered creating the installer with something other than NSIS? :confused:

  • Thanks 1
Posted

Thanks Arthur. I had not thought of having a shortcut to the folder, that would make it much easier and solves the main problem around hidden files.

 

What would you recommend instead of NSIS? I only choose it because of past experience needing to repack VLC installer for school network and VLC uses it.

Posted
What would you recommend instead of NSIS?

Something that can create MSIs would be might first choice since it's the most flexible. Schools can easily deploy MSIs through Group Policy if they don't have SCCM, MDT, PDQ Deploy etc. already in place and IT managers can customise what the installer does prior to deployment e.g. stop it dumping shortcuts all over the desktop and Start menu (most of which often aren't needed). ;)

 

My next choice would probably be InnoSetup. This creates EXE installers but has more command-line parameters available for customising what the installer does during deployment. NSIS is rather limited by comparison with just /S and /D.

 

That said, considering the code for your NSIS installer is available from Github anyone who wants to customize the installer or repackage it can do so. :D

  • Thanks 1

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...