From: Dennis on

Thanks for the information. I have a little bit of reading, some testing,
and a lot of head scratching.


From: Paul Shapiro on
You can get the db directory with CurrentDB.Name, which returns the complete
path and file name. That would eliminate one of the global variables.

"Rod Plastow" <RodPlastow(a)> wrote in message
> Dennis,
> To extend Jeanette's reply [Jeanette: I apologise for butting in] - a
> couple
> of features you might like to consider and that may eliminate the need for
> an
> INI file are:
> 1. Storing data in the CurrentProject.Properties collection. These values
> will apply globally to your application irrespective of user. The useful
> things is the data is persistent between sessions.
> 2. Storing data in the registry. If you don't know them, look up the
> SaveSetting, GetSetting, etc. statements. Here VBA stores the data in the
> HKEY_CURRENT_USER hive so the data can be different for each user. Again
> the
> data is persistent between sessions.
> #2 of course falls down if you move the applcation to another machine -
> but
> then so does an INI file solution. There are also some useful built in
> functions that return the current user, whether the application was
> started
> by that user or Automation, etc.
> Have fun!
> Rod
> PS You ask whether there are other uses for global variables. The trite
> answer is use a global variable for any data that applies to the
> application
> as a whole; your use of user-specific data is a good example. However
> like
> Jeanette I prefer to keep global variables per se to a minimum. When
> necessary I place all such variables together with enums, etc. in a
> clearly
> named module, a module that contains nothing else but these 'definitions.'
> They are then easy to find and review.