data persistence - best practice advice

[mirandacascade]

Assume the following:
1) multi-user environment
2) when user opens app, want to run some code that retrieves some
information specific to the user...retrievi ng this information is
somewhat i/o intensive, so would prefer to retrieve the info once at
the beginning of the session, and have the data persist for the
session
3) several forms in the app need to reference the information
retrieved in #2 (the information specific to the user)
4) would prefer to have a solution where the information specific to
the user (the info retrieved in #2) is NOT stored in a table...instead
the information is stored in a VB data structure, and the VB code is
organized such that:
a) the data structure gets initialized when the user opens the app
b) the information in the data structure persists while the user has
the app open
c ) the data structure is such that the code behind the forms that
need the data have 'visibility' to the data in that data structure

So, my questions are:
1) Is there a 'best practices' way of setting up the VB data structure
to handle the situation described above? If so, what would the
outline of that be for this situation?
2) Is this, perhaps, a good candidate for the use of a class module?

Thank you.

[Rick Brandt]

mi************@ yahoo.com wrote:

Assume the following:
1) multi-user environment
2) when user opens app, want to run some code that retrieves some
information specific to the user...retrievi ng this information is
somewhat i/o intensive, so would prefer to retrieve the info once at
the beginning of the session, and have the data persist for the
session
3) several forms in the app need to reference the information
retrieved in #2 (the information specific to the user)
4) would prefer to have a solution where the information specific to
the user (the info retrieved in #2) is NOT stored in a table...instead
the information is stored in a VB data structure, and the VB code is
organized such that:
a) the data structure gets initialized when the user opens the app
b) the information in the data structure persists while the user has
the app open
c ) the data structure is such that the code behind the forms that
need the data have 'visibility' to the data in that data structure

So, my questions are:
1) Is there a 'best practices' way of setting up the VB data structure
to handle the situation described above? If so, what would the
outline of that be for this situation?
2) Is this, perhaps, a good candidate for the use of a class module?

Thank you.

Class module or just a hidden form with various controls to hold the values.
You could use global variables but they can lose their values if an unhandled
error occurs (MDB, not MDE). Class objects and hidden forms would not have this
issue.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com

[Tom van Stiphout]

On Wed, 5 Dec 2007 17:26:14 -0800 (PST), mi************@ yahoo.com
wrote:

YES! This is perfect for a class module. There is nothing wrong with
declaring a more classic Type and having a global variable reference
it, but an object representing the user is much more elegant and
versatile.

Start your application with an AutoExec macro (rather than a startup
form). It has just one command: RunCode, InitApplication ()
In a standard module write the public function InitApplication , which
as part of its processing (before opening the first form) creates a
global user object of the type referenced in your class module, and
populates it, perhaps by calling an Init method.
Then throughout your app you have access to that object through the
global variable. g_User.FirstNam e, etc.

-Tom.

>Assume the following:
1) multi-user environment
2) when user opens app, want to run some code that retrieves some
information specific to the user...retrievi ng this information is
somewhat i/o intensive, so would prefer to retrieve the info once at
the beginning of the session, and have the data persist for the
session
3) several forms in the app need to reference the information
retrieved in #2 (the information specific to the user)
4) would prefer to have a solution where the information specific to
the user (the info retrieved in #2) is NOT stored in a table...instead
the information is stored in a VB data structure, and the VB code is
organized such that:
a) the data structure gets initialized when the user opens the app
b) the information in the data structure persists while the user has
the app open
c ) the data structure is such that the code behind the forms that
need the data have 'visibility' to the data in that data structure

So, my questions are:
1) Is there a 'best practices' way of setting up the VB data structure
to handle the situation described above? If so, what would the
outline of that be for this situation?
2) Is this, perhaps, a good candidate for the use of a class module?

Thank you.

[rkc]

Tom van Stiphout wrote:

On Wed, 5 Dec 2007 17:26:14 -0800 (PST), mi************@ yahoo.com
wrote:

YES! This is perfect for a class module. There is nothing wrong with
declaring a more classic Type and having a global variable reference
it, but an object representing the user is much more elegant and
versatile.

Start your application with an AutoExec macro (rather than a startup
form). It has just one command: RunCode, InitApplication ()
In a standard module write the public function InitApplication , which
as part of its processing (before opening the first form) creates a
global user object of the type referenced in your class module, and
populates it, perhaps by calling an Init method.
Then throughout your app you have access to that object through the
global variable. g_User.FirstNam e, etc.

-Tom.

Better yet is a public function that returns a reference to a private
User object. That way the object can be returned when it exists or
created and initialized if it doesn't. There's no need to create it at
startup. It's created the first time it is used.

[Tom van Stiphout]

On Wed, 05 Dec 2007 22:00:11 -0500, rkc <rk*@rkcny.yabb a.dabba.do.com>
wrote:

That's a good idea in some appliations, but the OP wrote:
"when user opens app, want to run some code that retrieves some
information specific to the user", so I fugured it would be
appropriate to initialize the object at startup time.

Do you have a code sample of the finer points of your implementation?

-Tom.

>Tom van Stiphout wrote:

>On Wed, 5 Dec 2007 17:26:14 -0800 (PST), mi************@ yahoo.com
wrote:

YES! This is perfect for a class module. There is nothing wrong with
declaring a more classic Type and having a global variable reference
it, but an object representing the user is much more elegant and
versatile.

Start your application with an AutoExec macro (rather than a startup
form). It has just one command: RunCode, InitApplication ()
In a standard module write the public function InitApplication , which
as part of its processing (before opening the first form) creates a
global user object of the type referenced in your class module, and
populates it, perhaps by calling an Init method.
Then throughout your app you have access to that object through the
global variable. g_User.FirstNam e, etc.

-Tom.

Better yet is a public function that returns a reference to a private
User object. That way the object can be returned when it exists or
created and initialized if it doesn't. There's no need to create it at
startup. It's created the first time it is used.

[Tom van Stiphout]

On Wed, 5 Dec 2007 19:47:10 -0600, "Rick Brandt"
<ri*********@ho tmail.comwrote:

Agreed on the hidden form, but the class object is likely referenced
by a global variable, which would suffer from the same "unhandled
error" issue.

-Tom.

>mi************ @yahoo.com wrote:

>Assume the following:
1) multi-user environment
2) when user opens app, want to run some code that retrieves some
information specific to the user...retrievi ng this information is
somewhat i/o intensive, so would prefer to retrieve the info once at
the beginning of the session, and have the data persist for the
session
3) several forms in the app need to reference the information
retrieved in #2 (the information specific to the user)
4) would prefer to have a solution where the information specific to
the user (the info retrieved in #2) is NOT stored in a table...instead
the information is stored in a VB data structure, and the VB code is
organized such that:
a) the data structure gets initialized when the user opens the app
b) the information in the data structure persists while the user has
the app open
c ) the data structure is such that the code behind the forms that
need the data have 'visibility' to the data in that data structure

So, my questions are:
1) Is there a 'best practices' way of setting up the VB data structure
to handle the situation described above? If so, what would the
outline of that be for this situation?
2) Is this, perhaps, a good candidate for the use of a class module?

Thank you.

Class module or just a hidden form with various controls to hold the values.
You could use global variables but they can lose their values if an unhandled
error occurs (MDB, not MDE). Class objects and hidden forms would not have this
issue.

[David W. Fenton]

rkc <rk*@rkcny.yabb a.dabba.do.comw rote in
news:47******** **************@ roadrunner.com:

Better yet is a public function that returns a reference to a
private User object. That way the object can be returned when it
exists or created and initialized if it doesn't. There's no need
to create it at startup. It's created the first time it is used.

I'm not sure what you mean by a private "User object." You can write
functions that return values stored anywhere, and if they are data
that doesn't change during a user session, then you can use a STATIC
variable in the function and initialize it the first time the
function is called (though that doesn't work with Boolean
variables). I use this technique all the time so that things like
Windows logon and workstation name get looked up only once, the
first time the function is called.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/