Is this a good reason for a front end table

[Guest]

I have one table called "Providers" and another called "User preferences."
When I split the DB, they went to the backend, and the software calls the
last used Provider to be the one that populates the front end data on a
couple forms.

I want this data to be remembered on each frontend, so they don't have to
always do a manual change looking for their name in a search window.

Should I add tables to the front end after the DB split?
If I do, will the program know to look first in the local directory, then
2nd in the backend server for the information?
THank you,
Karl

 

[Guest]

If the table exist in the frontend, Access will only look there for those
tables.

Local tables are good for data that will rarely change or for storing user
specific preferences.

Anything you want to be available to all FE's must be in the backend DB.

Steve

 

[Guest]

Thanks Steve,
Can the local tables be duplicates of the backend?
Right now I have backup and import forms that work on these tables. I'm
confused about which table, front or back, will be backed up. Probably I
should just delete these front end tables from the backend, eh?
Or, will Access just use the FE table preferentially over the BE, so I don't
need to worry about it?

Karl

 

[Guest]

If your frontend has the tables, it will ignore those in the backend. You
don't need them in the backend unless you are using them in another frontend
that doesn't have them locally. If that is the case, you may aswell have them
just in the BE but then those records will be relevant to all users.

Local tables are specific to the user of that FE. Linked tables are
available to all users.

Steve

 

[Guest]

If your frontend has the tables, it will ignore those in the backend. You
don't need them in the backend unless you are using them in another frontend
that doesn't have them locally. If that is the case, you may aswell have them
just in the BE but then those records will be relevant to all users.

Local tables are specific to the user of that FE. Linked tables are
available to all users.

Steve

 

[Guest]

Very good-thanks again!
Karl

If your frontend has the tables, it will ignore those in the backend. You
don't need them in the backend unless you are using them in another frontend
that doesn't have them locally. If that is the case, you may aswell have them
just in the BE but then those records will be relevant to all users.

Local tables are specific to the user of that FE. Linked tables are
available to all users.

Steve

 

[Tony Toews [MVP]]

I have one table called "Providers" and another called "User preferences."
When I split the DB, they went to the backend, and the software calls the
last used Provider to be the one that populates the front end data on a
couple forms.

I want this data to be remembered on each frontend, so they don't have to
always do a manual change looking for their name in a search window.

Should I add tables to the front end after the DB split?
If I do, will the program know to look first in the local directory, then
2nd in the backend server for the information?

Don't user tables in the FE. Keep the tables in the backend with
records by user id. See API: Get Login name
http://www.mvps.org/access/api/api0008.htm

Otherwise when you give the user a new copy of the FE they've lost all
thier settings.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Guest]

Hi Tony,
Thanks for your response. I think I'm missing a step, though. Right now,
users don't have to login, but I should probably make them do so, then have
the login retrieve their personal information which would populate the forms
with their names.

Keeping tables in the BE does sound better, but can you direct me toward
information to fill the gap between my current setup and the one where this
module would help?
Thank you,
Karl

 

[Tony Toews [MVP]]

Thanks for your response. I think I'm missing a step, though. Right now,
users don't have to login, but I should probably make them do so, then have
the login retrieve their personal information which would populate the forms
with their names.

Don't they have to login to the network? I don't mean logging into
Access.

Keeping tables in the BE does sound better, but can you direct me toward
information to fill the gap between my current setup and the one where this
module would help?

Well, this will require some VBA code.

Determine if the user already exists on that table. If not then add a
record with the current user name.

On a form, let's call it UserOptionsHidden, put the user table in the
record source. Then open the form with the where parameter set to the
user field and user name. So now that form has that users fields on
it. Make all the fields locked true and enabled no.

Now you can reference that form data as required. That is if you
need a particular field from it you can use
Forms!UsersOptionsHidden!FieldA.

Once you're comfortable that it works then you open that form with the
hidden parameter so the users don't even know it exists.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/