[AccessD] The future of Access, .NET and SQL

>Is it better to import tables to sysvars or sysvars into existing db

I'm not sure exactly what you are asking but the way I use SysVars, I have a
table of SysVars that controls the framework.  That table has a copy in the
framework that is loaded by the framework as it initializes.  It controls
such things as:

Do you want JIT Subforms turned on by default
What is the default date format
Etc.

Thus the call to FWInit causes the FWSysVars table INSIDE of the framework
MDA to load.  Once that is loaded, it looks for a copy of FWSysVars in the
FE.  This is an "override" table.  IOW, by default, JIT Subforms may be
false, but for THIS FE, JIT SubForms needs to be on by default.  Thus I
literally copy the FWSysVars table from the framework MDA into every FE as
one of the first steps of setting up a FE.  I can then edit the FW defaults
per the needs of THAT FE.

So... I have a SysVar table that controls the FRAMEWORK, with a copy that
loads immediately from inside the framework library and then an override
table that loads from the FE which can override any defaults on a FE by FE
basis.

I usually then have what I call an SVAPPControl table, or a table of SysVars
to control the CODE in the application.  Perhaps the app needs steering
logic to decide whether to turn on particular forms or reports or modules of
code.  By setting SysVars in the SVAppControl table you can cause code to
branch particular ways.  

The SVAppControl table is typically just another table that physically sits
in the framework MDA but is empty.  The framework loads the table and sets
up a SVAppControl class for the application to reference, but it doesn't
have anything in it.  I then copy the empty SVAppContr table into the FE and
start loading SVs into the table as I find a need for them as I am
developing the app.  Thus let's say I add 15 SVAppControl variables into the
copy in the FE.  As the framework loads, it loads the FWSysvars table and
override table, it loads the SVAppControl (empty) from the Framework MDA and
then loads the now populated SVAppControl from the FE and by the time the
Framework is finished initializing that table is ready for the FE
application code to use.

I also have a third SVAppDATA table.  This is a table of application DATA
sysvars.  Things like my company (ColbyConsulting) contact information, the
same kind of info about the CLIENT'S company, perhaps for use on reports
etc.  The process is the same though.  There is an empty copy of the table
in the SysVar that gets loaded as the framework initializes.  I then copy
that empty table into my BACK END (typically) so that even if there is more
than one FE they all share the same info, although it is possible to have an
"override" table located in the FE that can override the one in the BE if a
specific FE needs different AppData.  Again though, as the framework loads,
it loads the empty copy in the Framework container, then looks for and loads
the one in the BE/FE.  By the time the framework is finished loading, the
AppDATA SysVar table is finished loading and is ready for the application to
use.

Thus in my applications I have THREE "sets" of SysVar tables.  

SVFramework
SVAppControl
SVAppData

All of these have the tables named and ready to go in the framework
container.  As I build the empty FE I pull all three into the FE, pulling
the SVAppDATA into the BE as well, and linking it into the FE.  I can then
load SysVars into the various tables as I desire and they are just loaded by
the Framework as it initializes so that by the time the FWInit() function
returns control to the FE loader, all three tables have been initialized.

By the time I am done, I have THREE functions I can call to get data out of
the various SysVar tables.

SVFW("SomeSysVarName") will return the value of the SysVar named
"SomeSysVarName" from the FRAMEWORK SysVar table (cached of course).

SVAppContr("SomeAppCONTROLSysVarName") will return the value of the SysVar
named "SomeAppCONTROLSysVarName" from the APPLICATION CONTROL SysVar table
(cached of course).

SVAppData("SomeAppDATASysVarName") will return the value of the SysVar named
"SomeAppDATASysVarName" from the APPLICATION DATA SysVar table (cached of
course).

SysVar tables are a type of cache, loaded out of the tables into a class
structure.  I do this intentionally so that the program can access these
variables at full program speed instead of having to access the table out in
the database container whenever it needs to use a SysVar.  Sysvars are
lightening fast, but because they are a cache, if you add something to the
SysVar table, the application won't pick it up until the next time the
SysVar tables are loaded into the class cache system.  In practice this
isn't an issue since these variables are not changed on a moment by moment
basis, but rather loaded as you build the app and then rarely change.  The
SVAppDATA table changes the most frequently, but again even this is on a
very occasional basis, not daily.

I hope this has answered your questions about how I use them, where the
tables come from, where I place them and how they get loaded.

John W. Colby
www.ColbyConsulting.com 

Contribute your unused CPU cycles to a good cause:
http://folding.stanford.edu/

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Joe Hecht
Sent: Friday, September 30, 2005 1:32 AM
To: 'Access Developers discussion and problem solving'
Subject: Re: [AccessD] The future of Access, .NET and SQL


John,

Bless you for sysvars. I am still learning to work with them.

Is it better to import tables to sysvars or sysvars into existing db

Joe