Hello All

i have a database that users use over a thin client setup.

currently i use a combination of a combo box and columns in the combo box to
filter, and limit the users capabilities. basically i turn on and off buttons
because of the value of a column in the employee combo box. basically the
combo box lists the user and becomes an object that i can use to manipulate
data and code.

my question is this, is this the best way of doing this or would it be
better to create, what in my limited understanding of code, i think would be
called a "class module" that loads the user "object" that has all the same
information that i currently store in the combo box.

i dont have much experience with classes but i am starting to think that i
might be able to be more efficient in my system of filtering and manipulating
buttons and stuff.

any suggestions or comments?

Access is not a client-server database, so unless you're using a stripped
down, bare-bones PC, you may want to clarify what you mean by 'thin client'
to begin with. Access is file based. Regardless of the location of the .mdb
file the PC that is actually running Access is doing all of the work.

Also, what do you mean by 'becomes an object that i can use to manipulate
data and code'? How are you accessing the data to see if a particular button
should be available or not? Are you actually changing the .Visible or
..Enabled properties of the buttons to control their function or do you have
code that checks if the code behind the button can be run by the user?

Inquiring minds want to know....


"DawnTreader" wrote:

> Hello All
>
> i have a database that users use over a thin client setup.
>
> currently i use a combination of a combo box and columns in the combo box to
> filter, and limit the users capabilities. basically i turn on and off buttons
> because of the value of a column in the employee combo box. basically the
> combo box lists the user and becomes an object that i can use to manipulate
> data and code.
>
> my question is this, is this the best way of doing this or would it be
> better to create, what in my limited understanding of code, i think would be
> called a "class module" that loads the user "object" that has all the same
> information that i currently store in the combo box.
>
> i dont have much experience with classes but i am starting to think that i
> might be able to be more efficient in my system of filtering and manipulating
> buttons and stuff.
>
> any suggestions or comments?

On Jul 31, 7:06*pm, dch3 <d...@discussions.microsoft.com> wrote:
> Access is not a client-server database, so unless you're using a stripped
> down, bare-bones PC, you may want to clarify what you mean by 'thin client'
> to begin with. Access is file based. Regardless of the location of the .mdb
> file the PC that is actually running Access is doing all of the work.
>
> Also, what do you mean by 'becomes an object that i can use to manipulate
> data and code'? How are you accessing the data to see if a particular button
> should be available or not? Are you actually changing the .Visible or
> .Enabled properties of the buttons to control their function or do you have
> code that checks if the code behind the button can be run by the user?
>
> Inquiring minds want to know....
>
>
>
> "DawnTreader" wrote:
> > Hello All
>
> > i have a database that users use over a thin client setup.
>
> > currently i use a combination of a combo box and columns in the combo box to
> > filter, and limit the users capabilities. basically i turn on and off buttons
> > because of the value of a column in the employee combo box. basically the
> > combo box lists the user and becomes an object that i can use to manipulate
> > data and code.
>
> > my question is this, is this the best way of doing this or would it be
> > better to create, what in my limited understanding of code, i think would be
> > called a "class module" that loads the user "object" that has all the same
> > information that i currently store in the combo box.
>
> > i dont have much experience with classes but i am starting to think that i
> > might be able to be more efficient in my system of filtering and manipulating
> > buttons and stuff.
>
> > any suggestions or comments?- Hide quoted text -
>
> - Show quoted text -

thin client is where the user logs into a terminal server. this really
has nothing to do with my question.

i have a combo box that i use to show the name of the person logged
in. they cant change anything in the combo box, but i have given it
columns that store the data as to what the "rights" of the user are.
then in my code i use that data to allow buttons to be visible and
enabled and forms to auto fill the user and so on... so yes.

-There are times were individuals here do not understand that Access is not a
client-server database. Its all file based.

-You're better off using global variables to capture and access information
in this scenario as you're counting on the Form that the ComboBox is residing
on always being opened. Its just a matter of loading them up at startup.
While the data is in a global variable, I would actually retreive the values
via a Function so that if the variable shows up as Null or Zero-length (for
whatever reason), you can reset it by hitting the table again. This serves to
minimize the number of times that you're getting the values from the table,
should help with performance and ensures that the variables are always set.

As in...

Function getWindowsUserId()

'Set the value if we don't have it; avoids having to set it when the
application loads and
'resets it in the event that the value is lost for any reason.
If Len(gWindowsUserId) = 0 Then setWindowsUserId

getWindowsUserId = gWindowsUserId

End Function

setWindowsUserId is a function that get the person's name from Active
Directory which caused a major performance hit. While different, the
principle is the same.

"DawnTreader" wrote:

> On Jul 31, 7:06 pm, dch3 <d...@discussions.microsoft.com> wrote:
> > Access is not a client-server database, so unless you're using a stripped
> > down, bare-bones PC, you may want to clarify what you mean by 'thin client'
> > to begin with. Access is file based. Regardless of the location of the .mdb
> > file the PC that is actually running Access is doing all of the work.
> >
> > Also, what do you mean by 'becomes an object that i can use to manipulate
> > data and code'? How are you accessing the data to see if a particular button
> > should be available or not? Are you actually changing the .Visible or
> > .Enabled properties of the buttons to control their function or do you have
> > code that checks if the code behind the button can be run by the user?
> >
> > Inquiring minds want to know....
> >
> >
> >
> > "DawnTreader" wrote:
> > > Hello All
> >
> > > i have a database that users use over a thin client setup.
> >
> > > currently i use a combination of a combo box and columns in the combo box to
> > > filter, and limit the users capabilities. basically i turn on and off buttons
> > > because of the value of a column in the employee combo box. basically the
> > > combo box lists the user and becomes an object that i can use to manipulate
> > > data and code.
> >
> > > my question is this, is this the best way of doing this or would it be
> > > better to create, what in my limited understanding of code, i think would be
> > > called a "class module" that loads the user "object" that has all the same
> > > information that i currently store in the combo box.
> >
> > > i dont have much experience with classes but i am starting to think that i
> > > might be able to be more efficient in my system of filtering and manipulating
> > > buttons and stuff.
> >
> > > any suggestions or comments?- Hide quoted text -
> >
> > - Show quoted text -
>
> thin client is where the user logs into a terminal server. this really
> has nothing to do with my question.
>
> i have a combo box that i use to show the name of the person logged
> in. they cant change anything in the combo box, but i have given it
> columns that store the data as to what the "rights" of the user are.
> then in my code i use that data to allow buttons to be visible and
> enabled and forms to auto fill the user and so on... so yes.
>

On Aug 2, 8:36*am, dch3 <d...@discussions.microsoft.com> wrote:
> -There are times were individuals here do not understand that Access is not a
> client-server database. Its all file based.
>
> -You're better off using global variables to capture and access information
> in this scenario as you're counting on the Form that the ComboBox is residing
> on always being opened. Its just a matter of loading them up at startup.
> While the data is in a global variable, I would actually retreive the values
> via a Function so that if the variable shows up as Null or Zero-length (for
> whatever reason), you can reset it by hitting the table again. This serves to
> minimize the number of times that you're getting the values from the table,
> should help with performance and ensures that the variables are always set.
>
> As in...
>
> Function getWindowsUserId()
>
> * * 'Set the value if we don't have it; avoids having to set it when the
> application loads and
> * * 'resets it in the event that the value is lost for any reason.
> * * If Len(gWindowsUserId) = 0 Then setWindowsUserId
>
> * * getWindowsUserId = gWindowsUserId
>
> End Function
>
> setWindowsUserId is a function that get the person's name from Active
> Directory which caused a major performance hit. While different, the
> principle is the same.
>
>
>
> "DawnTreader" wrote:
> > On Jul 31, 7:06 pm, dch3 <d...@discussions.microsoft.com> wrote:
> > > Access is not a client-server database, so unless you're using a stripped
> > > down, bare-bones PC, you may want to clarify what you mean by 'thin client'
> > > to begin with. Access is file based. Regardless of the location of the .mdb
> > > file the PC that is actually running Access is doing all of the work.
>
> > > Also, what do you mean by 'becomes an object that i can use to manipulate
> > > data and code'? How are you accessing the data to see if a particularbutton
> > > should be available or not? Are you actually changing the .Visible or
> > > .Enabled properties of the buttons to control their function or do you have
> > > code that checks if the code behind the button can be run by the user?
>
> > > Inquiring minds want to know....
>
> > > "DawnTreader" wrote:
> > > > Hello All
>
> > > > i have a database that users use over a thin client setup.
>
> > > > currently i use a combination of a combo box and columns in the combo box to
> > > > filter, and limit the users capabilities. basically i turn on and off buttons
> > > > because of the value of a column in the employee combo box. basically the
> > > > combo box lists the user and becomes an object that i can use to manipulate
> > > > data and code.
>
> > > > my question is this, is this the best way of doing this or would itbe
> > > > better to create, what in my limited understanding of code, i thinkwould be
> > > > called a "class module" that loads the user "object" that has all the same
> > > > information that i currently store in the combo box.
>
> > > > i dont have much experience with classes but i am starting to thinkthat i
> > > > might be able to be more efficient in my system of filtering and manipulating
> > > > buttons and stuff.
>
> > > > any suggestions or comments?- Hide quoted text -
>
> > > - Show quoted text -
>
> > thin client is where the user logs into a terminal server. this really
> > has nothing to do with my question.
>
> > i have a combo box that i use to show the name of the person logged
> > in. they cant change anything in the combo box, but i have given it
> > columns that store the data as to what the "rights" of the user are.
> > then in my code i use that data to allow buttons to be visible and
> > enabled and forms to auto fill the user and so on... so yes.- Hide quoted text -
>
> - Show quoted text -

k. thanks. you haven't answered my question. you have moved to a topic
that you wanted to talk about.

i may not be further developing the application for it to matter
anymore, thanks for trying anyways.

You asked the question "is this the best way of doing this".

"DawnTreader" wrote:

> On Aug 2, 8:36 am, dch3 <d...@discussions.microsoft.com> wrote:
> > -There are times were individuals here do not understand that Access is not a
> > client-server database. Its all file based.
> >
> > -You're better off using global variables to capture and access information
> > in this scenario as you're counting on the Form that the ComboBox is residing
> > on always being opened. Its just a matter of loading them up at startup.
> > While the data is in a global variable, I would actually retreive the values
> > via a Function so that if the variable shows up as Null or Zero-length (for
> > whatever reason), you can reset it by hitting the table again. This serves to
> > minimize the number of times that you're getting the values from the table,
> > should help with performance and ensures that the variables are always set.
> >
> > As in...
> >
> > Function getWindowsUserId()
> >
> > 'Set the value if we don't have it; avoids having to set it when the
> > application loads and
> > 'resets it in the event that the value is lost for any reason.
> > If Len(gWindowsUserId) = 0 Then setWindowsUserId
> >
> > getWindowsUserId = gWindowsUserId
> >
> > End Function
> >
> > setWindowsUserId is a function that get the person's name from Active
> > Directory which caused a major performance hit. While different, the
> > principle is the same.
> >
> >
> >
> > "DawnTreader" wrote:
> > > On Jul 31, 7:06 pm, dch3 <d...@discussions.microsoft.com> wrote:
> > > > Access is not a client-server database, so unless you're using a stripped
> > > > down, bare-bones PC, you may want to clarify what you mean by 'thin client'
> > > > to begin with. Access is file based. Regardless of the location of the .mdb
> > > > file the PC that is actually running Access is doing all of the work.
> >
> > > > Also, what do you mean by 'becomes an object that i can use to manipulate
> > > > data and code'? How are you accessing the data to see if a particular button
> > > > should be available or not? Are you actually changing the .Visible or
> > > > .Enabled properties of the buttons to control their function or do you have
> > > > code that checks if the code behind the button can be run by the user?
> >
> > > > Inquiring minds want to know....
> >
> > > > "DawnTreader" wrote:
> > > > > Hello All
> >
> > > > > i have a database that users use over a thin client setup.
> >
> > > > > currently i use a combination of a combo box and columns in the combo box to
> > > > > filter, and limit the users capabilities. basically i turn on and off buttons
> > > > > because of the value of a column in the employee combo box. basically the
> > > > > combo box lists the user and becomes an object that i can use to manipulate
> > > > > data and code.
> >
> > > > > my question is this, is this the best way of doing this or would it be
> > > > > better to create, what in my limited understanding of code, i think would be
> > > > > called a "class module" that loads the user "object" that has all the same
> > > > > information that i currently store in the combo box.
> >
> > > > > i dont have much experience with classes but i am starting to think that i
> > > > > might be able to be more efficient in my system of filtering and manipulating
> > > > > buttons and stuff.
> >
> > > > > any suggestions or comments?- Hide quoted text -
> >
> > > > - Show quoted text -
> >
> > > thin client is where the user logs into a terminal server. this really
> > > has nothing to do with my question.
> >
> > > i have a combo box that i use to show the name of the person logged
> > > in. they cant change anything in the combo box, but i have given it
> > > columns that store the data as to what the "rights" of the user are.
> > > then in my code i use that data to allow buttons to be visible and
> > > enabled and forms to auto fill the user and so on... so yes.- Hide quoted text -
> >
> > - Show quoted text -
>
> k. thanks. you haven't answered my question. you have moved to a topic
> that you wanted to talk about.
>
> i may not be further developing the application for it to matter
> anymore, thanks for trying anyways.
>

"There are times were individuals here do not understand that Access is not a
client-server database. Its all file based."

totally understand this. i use a terminal server setup to run my app for
those who need it overseas. check out this:

http://members.shaw.ca/albertkallal/Wan/Wans.html

"You're better off using global variables to capture and access information
in this scenario as you're counting on the Form that the ComboBox is residing
on always being opened."

my form with the "storage" combo box is always open. but this comment helps
me to understand a little better the inherent problem with the way i am
currently doing things. thanks.

"While the data is in a global variable, I would actually retreive the
values via a Function so that if the variable shows up as Null or Zero-length
(for whatever reason), you can reset it by hitting the table again. This
serves to minimize the number of times that you're getting the values from
the table, should help with performance and ensures that the variables are
always set. "

my combo box is loaded once. the recordset in it remains the same because
the user cannot interact with the combo box. i have it locked and the
dropdown arrow is covered with a rectangle. this causes it to look like the
box is just there to show thier name. but of course in behind the scenes it
is storing information on what they can and cant do.

i dont know what kind of performance hit that puts on the system. but at
this point it seems to work really well.

i want to apologize. i snapped at you the last post. in reality i barely
read your post mainly because i was angry with something that i was dealing
with at work and then i went off because i needed someone to shoot.

it isnt any better at work... i may end up not continuing the developement
of the app that i started almost 2 years ago, but then that isnt really what
i was hired for.

thanks for your help, you have helped me to understand more of what things i
need to think about for the next time around.