[AccessD] How to do an Admin Table

Building a Class is the key (IMHO).  On top of what you have described, I
would also have the Class contain a default value, so that no values would
be required in the table to begin with.

In fact (and I must admit I do this a lot in VB, because I use .mdb's as my
datasource, but usually use VB or ASP for FE), something I might suggest
expiramenting with, just for the Heck of it, would be to use the Implements
statement.  Not sure how well this would work with Access, but in VB, I have
had a WONDERFUL time with Implements.  Just wish I had more instances where
I could use it.

Possible scenario......

Create a Class that calls an sets an Implements Class.  Like this:

Dim myClass As ImplementedClass
Property Get SysValue(strName as String)
On Error Resume Next
Set myClass=CreateObject("MyProject." & strName)
If Err Then
	Err.Clear
	Set myClass=CreateObject("MyProject.DefaultClass")
End if
SysValue=myClass.Value
End Property

Now, with that class, you would absolutely need the 'DefaultClass' Class, so
that if it can't find the appropriate class, it has something to fall on.

But, and this is where it gets cool (at least from a VB perspective.), not
only can I change the values from the FE, or BE, but I can change how the
Class works by just registering a new Class.  (In VB, that would just be
registering a new .dll). New Changes would automatically be taken into
affect.  So if I want to change a 'values' default value, or even do some
type of business logic on a value, or error handling/prevention, no need to
change the main project, I just send out a new .dll with the new implemented
classes.  

I love Implements!

Drew


-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John W. Colby
Sent: Friday, February 06, 2004 2:10 PM
To: Access Developers discussion and problem solving
Subject: RE: [AccessD] How to do an Admin Table


John,

For a demo see www.colbyconsulting.com .

I use what I call a SysVar table.  However I would suggest using a record
for every variable rather than a single record with a field for each
variable.  The structure I use is:

SV_ID		- Autonumber PK - never really used but...
SV_VarName	- The name of the system variable - Company Name, Developer
Name,
whatever.
SV_VarValue	- The value of that SysVar
SV_Memo	- A text description of the variable, default values etc.

There are many reasons for going this way, SysVars can be added and deleted
at will, it is trivial to update values programmatically if needed etc.

I have a class that I use for this.  The class is fed a table name, and it
opens the table and reads the SysVars into a collection, with the collection
value  the VarValue and the Collection key the VarName.  The class then has
a function that allows you to pass in a VarName and get back the VarValue.

I use these EVERYWHERE.  It is a very handy concept once you get the hang of
it.  As you know, I do a framework.  I use a SysVar table right in my
Framework Library that sets up default functionality for the framework.
Things like:

VarName gJITSFrms, VarValue True

Sets up the framework to default to using JIT subforms.

In my code I then do something like:

	If FWSysVar.VarVal(gJITSFrms) = true then
		'Run the code that allows a JIT Subform
	else
		'Run the code that turns off JIT Subforms
	endif

IOW I can actually control program flow based on SysVars, turn on and off or
otherwise modify behaviors of the program.

I can then put an identical SysVar table (same name) in my FE and OVERRIDE
the default values.  The class has a "Merge" property that reads values out
of a second table and "merges" it into the collection.  If the value being
read from the table is not already in the collection it is simply added in.
If the value being read from the table is already in the collection, it is
updated to the value being brought in.

This allows me to do things like "for THIS FE set the default JIT behavior
to false", i.e. don't use JIT as the default behavior.  In fact I have
developed a method of doing "overrides" on a form by form basis.  That is a
little beyond the scope of this email however.

I can then build a APPSysVars table where I place application specific
sysvars.  This can be SysVars that modify APPLICATION BEHAVIORS based on the
values in this SysVar table.

Another SysVar table can be used for Application specific DATA such as
Company Name, Company Tax ID etc.

As you can see, SysVars are just a wonderful place to throw these things and
doing it on a record basis rather than a "new field in a single record"
basis allows me to just hop over to the SysVar table ad add a new SysVar
record when I need to do some new thing.

As I mentioned, I have a working demo up on my site.  Click the C2DbSysVars
button.

John W. Colby
www.ColbyConsulting.com

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com]On Behalf Of John Clark
Sent: Friday, February 06, 2004 2:25 PM
To: accessd at databaseadvisors.com
Subject: [AccessD] How to do an Admin Table


Forgive me, if this is an easy one, but I've even asked someone that
teaches the Microsoft Access certification classes, and they didn't know
how to do this either--or maybe I wasn't clear, when I asked.

I have had many programs where it would be useful to have an "admin"
table. This table would contain one single record with information
referenced in other parts of the program. For instance, I have a program
that figures monthly mileage for our county legislators, but it is
currently setup so that the rates are hard-coded and I have to alter
them everytime they are changed. I would like the user to alter this
themselves.

I have also thought about using this for programs--maybe in their
splash screens--to list the current directors names, and other info that
may or may not change in the future.

Any ideas how?

Thanks ahead of time...because I know if it can be done, somebody on
this list knows how to do it!!!

John W Clark

John W. Clark
Computer Programmer
Niagara County
Central Data Processing
_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com



_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com