0

I have very a rudimentary understanding of Microsoft Access and VBA Code.

On my work desktop, I have Microsoft Office Professional Plus 2013 Access

I've been tasked to create a MS Access application with an Access DB.

I started developing an MS Access application with Forms , and the corresponding DB I'm using VBA code event handlers(or Event Procedures) for the UI control buttons.

I wanted to create a common configuration settings area for said application( like ASP.NET web application have web.config files or app.config files )

I failed to find anything similar for MS Access application development.

Could someone please provide me with an explanation as to how to implement an MS access implementation model/software design pattern for common configuration settings area that is modular, reusable, clear and concise?

crazyTech
  • 1,379
  • 3
  • 32
  • 67
  • 1
    Create a module and put the configuration settings there? That's typically what I do in a VBA project. If you're looking for something more elaborate than that, then it might be useful to be a bit more detailed about what it is you're looking to implement. – Tim Williams Oct 23 '19 at 14:55
  • Thx, it is a typical Thick Client application with UI and an access DB. I just need to have a typical "template" file with the settings. It be nice if it were an xml or text file( as opposed to a code file) because if I need to change it then I don't have to edit code files. Could you provide some suggestions as to how I should do this? – crazyTech Oct 23 '19 at 14:59
  • 1
    There's nothing built-in like that - if you want something along those lines you'd need to implement it - XML/JSON or plain text "ini" file could all work, depending on what settings you need to store. – Tim Williams Oct 23 '19 at 15:03
  • 1
    See this. https://stackoverflow.com/questions/49112116/assigning-a-value-to-variablenameofvariable/49116217#49116217 – Kostas K. Oct 23 '19 at 15:13
  • 1
    _I need to change it then I don't have to edit code files._ A (surprise) _table_ will fit that purpose. – Gustav Oct 23 '19 at 15:16
  • Personally, I recommend using database properties. You can create and set your own properties (be sure to check they don't conflict with existing ones), easily look them up, and can store data with any type without worrying about separate tables for integers, doubles, text, etc. – Erik A Oct 23 '19 at 16:16
  • all above comments are valid unless you edit your question and explain what exactly you are trying to achieve. – Krish Oct 23 '19 at 16:28

1 Answers1

1

As noted, I great way to do this is to simply create a table in the front end. It is assumed that you will split your database into two parts. The code/forms etc. is the so called front end,and then you have the back end part (the database - it can be a accDB file, or it can be say SQL server).

So the typical update and deploy of your software will be:

Re-link your tables from test database to the actual live production database.

Compile your accDB into a accDE.

Deploy this new updated "next" version of your software to all the desktops.

So, since any change or addition to settings will be in the new front end then any application wide settings you have will thus roll out with your update.

It often depends on the user base. In the case that we had multiple customer sites running our software, then using a local table would not suffice, since things like path names, connection strings to the database etc. are customer specific. So, in this case we moved the settings table out to a text file (setup.ini). So we now use a setup.ini file that is external to the program and assumed to be deployed in the same folder as the front end. On startup we use the windows API to read ".ini" files.

So, both ideas (external setup.ini) or a local table in the front end are rather good choices from a development cycle point of view.

So once you down the road in developing your application, and the table/data structure changes are down to a dull roar, then it is time to split your application. (use the built in split wizard for this). I will say that even for my .net applications, I still often use a external setup.ini file for settings, since once again with multiple customer sites, it not practical to have customer specific settings in the application as opposed to a external settings file.

Albert D. Kallal
  • 42,205
  • 3
  • 34
  • 51