1

I want to be able to put all of my database's settings, table layouts, queries forms - in short: everything that is relevant for its structure and behavior - into text files. This is of course to enable me to then track changes via SVN.

This answer offers a great base in that the scripts export/import all database objects as well as relations. I've added support for references, so the reference to my VBA-library DB doesn't get lost on reassembling the DB from text files.

Now to correctly reproduce the DB's behavior, I need to somehow carry over its settings (File - Options - Current Database) as well. There is this article in the MSDN that lists some of the arguments available to Application.GetOption(OptionName as String). But this list doesn't seem to be exhaustive with respect to the options available in MS Access 2013. (And I'd like to avoid having to hardcode every option's name...)

Is there a list of OptionNames for use with Application.GetOption available via VBA? Or is there another way to export or backup options? Is there a definitive list of all options' names?

Notes

  • I'd prefer to somehow obtain a list of available options at runtime, so I can setup the procedure once and forget about it.
  • If that's not possible, I'd likely resort to hardcoding the OptionNames I deem relevant. It's just neither elegant nor maintenance-free...
  • The first link's accepted answer advises to check in the stripped-down database stub as well to preserve settings. This would be my last resort, as versioning binary files is - in my opinion - ugly and impractical at best.
Inarion
  • 578
  • 3
  • 14

1 Answers1

0

This is not a trivial problem. It's not particularly difficult technically, but there is a lot of work involved in making this work right. The scripts you reference are a starting point.

It's not the comprehensive solution you are seeking (yet), but look at Rubberduck

kismert
  • 1,662
  • 1
  • 13
  • 19
  • Thanks for your contribution. I know about Rubberduck and am actually using it (although maybe less than I should). I do not quite understand your train of thought here: In what way do you envision RD to help me get those OptionNames? Or did you think more along the lines of RD being able to export settings? As far as I know, it doesn't currently support anything like that. (But I may be missing something.) – Inarion Jan 12 '18 at 08:37
  • I'm not sure I made sufficiently clear in my question that the decomposition and recomposition of my DB (including tables, queries, forms, modules, relations) is already working (seemingly) flawlessly. The only thing missing is the transfer of DB-specific settings (which in my case are required for the DB to function correctly). Do you think I should add that information to the question to make it more clear? – Inarion Jan 12 '18 at 08:44
  • 1
    A quick web search didn't reveal any more information on Access GetOptions other than the link you provided. You probably will have to code them yourself in your solution. I mentioned RubberDuck simply because it seems like a promising project that could do this in the future, but it doesn't do it now. – kismert Jan 12 '18 at 20:56