data persistence - best practice advice

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...retrieving 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.

Re: data persistence - best practice advice

mirandacascade@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...retrieving 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

Re: data persistence - best practice advice

On Wed, 5 Dec 2007 17:26:14 -0800 (PST), mirandacascade@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.FirstName, 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...retrieving 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.

Re: data persistence - best practice advice

Tom van Stiphout wrote:
> On Wed, 5 Dec 2007 17:26:14 -0800 (PST), mirandacascade@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.FirstName, 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.

Re: data persistence - best practice advice

On Dec 5, 8:26 pm, mirandacasc...@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...retrieving 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.

An ADODB recordset can be saved (and opened) locally as XML or in
Microsoft Advanced Data TableGram (ADTG) format. Such a recordset is
available throught the CurrentProject object of editions of Access >=
2000.
What advantage is there to using a VB DataStructure over this more or
less native and available component of Access?

I created and used class modules extensivley in the previous century,
going so far as to write class modules that created generic class
modules for each exposed JET Table or Select Query (View). The notion
here was that each member of out development team would use these
generic class modules for appending, updating etc., helping with
standardizing our code.

My experience has been that class modules are much slower than
standard modules and that except in the rare situation when we need
more than one instance of a code structure within the same running
application, they are showy, but inefficient. I was hastened in coming
to this position when Property procedures in Standard Modules became
available. (Access 2000 or 2002? I'm not sure).

In some circumstances a form's recordset can be set to an ADODB
recordset.

Re: data persistence - best practice advice

On Wed, 05 Dec 2007 22:00:11 -0500, rkc
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), mirandacascade@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.FirstName, 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.

Re: data persistence - best practice advice

On Wed, 5 Dec 2007 19:47:10 -0600, "Rick Brandt"
wrote:

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.


>mirandacascade@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...retrieving 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.

Re: data persistence - best practice advice

rkc wrote in
news:475765ba$0$2339$4c368faf@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/