What is common practice?

  • Thread starter Thread starter Jim Franklin
  • Start date Start date
J

Jim Franklin

Hi,

Just something I have often wondered, as it crops up with almost every
application...

If you have a 1-record table which contains various settings for an
application, and those settings are used frequently in different functions
of the app, say via a function which opens the tbl_Settings recordset and
returns the appropriate field, is it more common (and more efficient) to run
the function every time a setting is needed, or to use a global variable,
and use the function only once at startup to assign the variable value.

I know this isn't a 'Help! How do I...' question, but if anyone can answer
this I would be very grateful,

Cheers,
Jim
 
It is a question of style, Jim, but I don't like globals because:

a) They lose their value when you reset your code, making them harder to
debug.

b) You have to restart the application before any change gets to them.

c) There's always the problem of a local variable being clobbered by a
global with the same name, and vice versa.

So my compromise is to read the value in the Load event of any form that
depends on it.

BTW, I also prefer to store these configuration settings/values as records
instead of fields in this table. This has the advantage of being more
flexible (you can easily add more settings, just with another record), but
the disadvantage that they are untyped (typically a Text (255) field, so you
must validate if it is to store a date or number.)
 
In
Jim Franklin said:
Hi,

Just something I have often wondered, as it crops up with almost every
application...

If you have a 1-record table which contains various settings for an
application, and those settings are used frequently in different
functions of the app, say via a function which opens the tbl_Settings
recordset and returns the appropriate field, is it more common (and
more efficient) to run the function every time a setting is needed,
or to use a global variable, and use the function only once at
startup to assign the variable value.
I know this isn't a 'Help! How do I...' question, but if anyone can
answer this I would be very grateful,
Click to expand...

I often define them as a set of global properties in a standard module,
with Property Let and Property Get procedures. Defined at the global
level in the module, I have private variables that are loaded with the
values from the table whenever they are currently empty -- so they are
loaded the first time they're called for, and also whenever a code reset
occurs and clears the variables. The Property Get procedures take care
of this, so they load the value from the table when needed, but just
pass back the value currently held in memory if it's already been
loaded. Property Let procedures, of course, update the table as well as
the private variables held in memory.

One reason I like this method is that I can call the Property Get
procedures to retrieve the settings in a query, without writing any
additional code.
 
In
Dirk Goldgar said:
I often define them as a set of global properties in a standard
module, with Property Let and Property Get procedures.
Click to expand...

I should mention that I also have a public procedure in that module to
force the reloading of the private variables, so any procedure that
updates the settings table directly can call it bring the properties up
to date afterwards. That relieves me of the need to close and reopen
the database, or reset the project, just to get the latest property
values loaded.
 
I just declare a global recordset, open it at startup.


Then, in code just go:


Areacode = gblrstDefaults!AreaCode

Since I often want the defaults to based as the actual default setting of a
control on a form, I also create a global function:

Public Function GetRidesDefault(strField As String) As Variant

On Error Resume Next
GetRidesDefault = gblRecRides(strField)

End Function


So, I can actually use the folwling expression in a forms control default
now:


=GetRidesDefault("AreaCode")

Further, I don't have a variable re-set problem due to un-handled errors
because I always supply a mde to my users..and mde's don't ever re-set
variables due to errors....
 
I prefer to use functions to return the value of 'global' variables. My
"Get" functions check to see if the variable has a stored value, if not, it
does a lookup in tblSettings (or prompt the user in some way or grabs the
value from an open form...). Otherwise it returns the value previously
looked-up (or subsequently set by the app). If, for some reason, code gets
reset or variables get wiped out, they'll just get looked up again.
(Conversely, my "Set" functions store new/changed values in tblSettings, for
future lookup.)

In general, my "global" variables are really private variables within a
general code module "modAppVariables", and can only be accessed via Get/Set
routines. So in a way I treat them like properties of an (imaginary) App
class, but without the actual Class. This allows be to use my GetVariable
functions from within code, forms, reports or queries (my stored queries
never use form/control references for criteria, just Get functions...). If
they were true class properties I would be limited to just the 1st item in
that list.

HTH,
 
You have some interesting suggestions. And I may consider one or two
of those. But I see they are quite different in many ways so to
answer your subject. There are lots of common practices. <smile>

However I use a hidden form bound to a Global Options table. When I
add new fields to the table I throw them on the form and then make
sure the fields are not visible.

Then I reference then as required by using
forms!GlobalOptionsHidden!goFieldName.

This also takes care of the bound form approach to ensure performance
to a database.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
If you have a 1-record table which contains various settings for
an application, and those settings are used frequently in
different functions of the app, say via a function which opens the
tbl_Settings recordset and returns the appropriate field, is it
more common (and more efficient) to run the function every time a
setting is needed, or to use a global variable, and use the
function only once at startup to assign the variable value.
Click to expand...

This is the perfect situation for a function using a static variable
internally. The first call will initialize the variable by looking
it up from the table. After that, it will just return the value of
the static variable. Should there be a code reset, it would look up
the value again.
 
I use a hidden form bound to a Global Options table. When I
add new fields to the table I throw them on the form and then make
sure the fields are not visible.

Then I reference then as required by using
forms!GlobalOptionsHidden!goFieldName.

This also takes care of the bound form approach to ensure
performance to a database.
Click to expand...

Assuming, of course, that your settings table is in the same back
end as the data tables. I tend to put settings like this in the
front end, as they are often related to user interface objects
(though I have no hard and fast rule on that).
 
I see they are quite different in many ways so to
answer your subject. There are lots of common practices. <smile>
Click to expand...

Good point <g>. 'Common practice' does not necessarily imply 'good
practice' or 'best practice'.

Jamie.

--
 
David W. Fenton said:
Assuming, of course, that your settings table is in the same back
end as the data tables. I tend to put settings like this in the
front end, as they are often related to user interface objects
(though I have no hard and fast rule on that).
Click to expand...

No, these are truly Global Options. Things such as tax rate
percentages and such. If I did have user specific settings, and I do
in some MDBs, I put those in their own table in the BE. With each
user having their own record using the API call to get the user name.

I wouldn't put anything in the FE as it could be updated at any time.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
I wouldn't put anything in the FE as it could be updated at any
time.
Click to expand...

One of my standard tables is tblReportDescriptions, which includes a
list of reports, and fields that control how the report is opened
(directly, or launched from a form that is opened first, or via code
that opens the report, as well as a bunch of other things). Given
that the reports are only in the front, I think this metadata that I
create also belongs in the front end, because putting in the back
end could then give users metadata about reports that are not yet
included in the version of the front end they are using.
 
David W. Fenton said:
One of my standard tables is tblReportDescriptions, which includes a
list of reports, and fields that control how the report is opened
(directly, or launched from a form that is opened first, or via code
that opens the report, as well as a bunch of other things). Given
that the reports are only in the front, I think this metadata that I
create also belongs in the front end, because putting in the back
end could then give users metadata about reports that are not yet
included in the version of the front end they are using.
Click to expand...

You're correct. I do something somewhat similar myself. If it's
database specific stuff that only I ever touch then yes I'd put that
in the FE.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
 
Back
Top