Demo: Application Parameters & Library Code

[Solo712]

In the OP about the merit of global variables in Access programs, I mentioned Juan Soto's as a promising approach to take. This is because in my thinking, global variables (and constants of course) very often hold info about the application settings and session parameters. It is not as much that I am offended by the use of globals as that I realize that very often things stored in them either need to propagate from one session to another, or are re-used from one session to another. So some kind of more permanent store is in order. And if they are stored in a table why copy them as variables in memory?

Clearly, this kind of data is independent (or nearly so) from the database itself. It represents items that have to do with managing an application in general, not individual tables and queries. Some information is by nature, parametric. Consider e.g. a parameter that records a monthly automatic run that updates Accounts Receivable for rents or monthly fees due. Clearly, this is a "one of" that does not relate to any of the AR tables but to automating business rules. So, each session of the Receivables the program would check the calendar and if the date is in the new month, it would update all accounts and then flip the date of the parameter. It goes without saying that this parameter would have to be stored and available to all subsequent sessions.

So I was attracted to Juan Soto's approach of combining a parametric table with the globals. It really made sense. When I analyzed his program I found a wealth of opportunities. I did not like much the idea of storing the global items in their native datatype. So I opted to store them all as strings. I also thought of a few things. One, there could be functional "sections" to manage the constant/variables and make it easier to view them in long lists. Two, I thought of adding some security, in recording who last changed the items and when. Also, the items should be protected against deleting and overwriting, and when they are deleted there could be an option of keeping them in the table and mark them as unusable. Finally, it occurred to me that since much of the parametric table would not change from one application to another that the table and functions to interact with it could be stored and referenced as an Access library. This means it could be used by several databases and represent sort of an application management standard of a developer.

So, I put a little demo together. I created the library table and code, and then a console to interact with the utility database. It's all provisional at the moment but I am keen to convert my present setup to this.

Hopefully, if nothing else, the demo delivers some helpful tips in the VBA modules on how to address objects in the library, both from within (CodeDb) and without (Set db = OpenDatabase).

Curious what the people here think.

Best,
Jiri

 

[isladogs]

Hi jiri

I remember your recent thread about global variables & thought it would be interesting to understand what this idea is all about.

First of all thanks for the effort you've put into this and for the detailed user guide which I've started reading & will finish later..

The reason I'm responding now is due to slight confusion about references comments on pg3-4
I have downloaded both databases to the same folder

When I first ran pConsole it started & loaded the form without error.
When I looked at the references, pConsole was listed (but not ticked).
The SysParms reference was not listed - neither present nor missing.

I closed it, opened the SysParms database then closed it again after looking at the table & form.
On reopening pConsole, the SysParms reference was present & ticked
The pConsole reference had disappeared.

Did I inadvertently get it to register itself somehow?

 

[Solo712]

Hi jiri

I remember your recent thread about global variables & thought it would be interesting to understand what this idea is all about.

First of all thanks for the effort you've put into this and for the detailed user guide which I've started reading & will finish later..

The reason I'm responding now is due to slight confusion about references comments on pg3-4
I have downloaded both databases to the same folder

When I first ran pConsole it started & loaded the for without error.
When I looked at the references, pConsole was listed (but not ticked).
The SysParms reference was not listed - neither present nor missing.

Interesting. In testing the library, I had a similar experience. I could not see at one point the library in the References even though the program ran. That of course means the pConsole program found the library. Still, I don't like these kinds of surprises. On second look, the reference was there. Similar issue arose when I compiled the SysParm and tried to replace the accdb with the accde version. Actually in that case, both files were appearing, with the one unselected eventually disappearing. Access is full of wonders, sometimes.

I closed it, opened the SysParms database then closed it again after looking at the table & form.
On reopening pConsole, the SysParms reference was present & ticked
The pConsole reference had disappeared. Did I inadvertently get it to register itself somehow?

I certainly did not add pConsole to the project References, so unfortunately I can't tell you how that happened. I hope it wasn't too much trouble to get it going. I originally wanted to supply the SysParm library as an .accde file but then I thought people would be ticked off not seeing the source. Still, the idea behind the library is basically to create a secure black box. However, that is not quite possible with Access. People will eventually find a way how to expose the Usys table and they will be able to link to it.

Best,
Jiri