[AccessD] Where to place path constants?

James Button jamesbutton at blueyonder.co.uk
Sun Mar 6 13:36:51 CST 2022


In addition to the OS and App related variables from within VBA.
There are the user environment values - system variables that you can preview by
looking at the response from SET in a command window.
Accessible using %APPDATA%" "%HOMEDRIVE%"  and "%HOMEPATH%" etc.

They may be of use for determining what the current 'user' has as their OS
environment.
But  beware of using all of them - as some may only be set within a particular
users environment.
And some - such as %PATH% can be quite long!

For use during a process within such as Excel I would suggest Public variables
at the start of a code module, but  they are only applicable for the execution
life of a "Macro".
For Access - definitely  a table such as  usysTblSysVars - where YOU can protect
them from user "manipulation".
Maybe  where there are multiple users of an app, include the relevant user id
and maybe creation timestamp as key columns so any diagnostics show who's
session  they are from.

JimB


-----Original Message-----
From: AccessD
<accessd-bounces+jamesbutton=blueyonder.co.uk at databaseadvisors.com> On Behalf Of
John Colby
Sent: Sunday, March 6, 2022 7:04 PM
To: Access Developers discussion and problem solving
<accessd at databaseadvisors.com>
Subject: Re: [AccessD] Where to place path constants?

I use what I call SysVars - System Variables.  I place them in a
usysTblSysVars which makes them invisible to the users.

SV_ID                 Autonumber PK
SV_VarName     Short Text     Variable Name
SV_VarValue      Short Text     Variable Value
SV_Memo           Long Text     Explanation for variable
SV_UserEditable Yes/No         Should be made user editable
SV_AllowOverride Yes/No        Can be overriden by the next table being
read in.  There may be SysVars that you don't want overridden

I then build a class to pull the sysvars out into sysVarinstances
Which I load into a class which reads all the sysvars from the table,
builds the instances, and loads the instances into a collection

This essentially caches them in memory and anywhere in the program where I
need to reference them in code, or even in a query, they are available to
me.

On Sun, Mar 6, 2022 at 8:08 AM Arthur Fuller <fuller.artful at gmail.com>
wrote:

> I'm revising an app that assumes some paths based on the drive letter and
> the project path. At the moment, it uses constants that are scattered
> throughout the app. I want to move them all into a single module,
> tentatively called modPathConstants, to minimize the find and replace
> hassles. Actually, the only thing that will change is the drive letter. The
> directory and subdirectory names will remain the same.
> I vaguely recall a function called ProjectPath() or somesuch. Guidance
> requested.
>
> --
> Arthur
> -- 



More information about the AccessD mailing list