Re: Find a record when Form opens


erick-flores wrote:
What about... forget all I said. And

You create a new User so he can use the database. This user has Admin
rights.

BAD design. That means that user can modify/delete ANYTHING in your
database, and completely wreck it. (Well, unless it's an MDE).

He logon to the application, and the form (to enter his information,
name, address, etc.) needs to be blank when it loads (because he is a
new user), he enter all his info and save his info

So base all the forms on queries, and filter for =CurrentUser() Then
the user can't see anything else.
Everything is working good but imagine if there are 50 users within the
application. The president logon to complete an expense report (thats
what this application is about) he does not want to be using the
navigation buttons to find his "profile" he just want to see directly
his information when the application loads, so he can fill his expense
report and print it w/o losing much time, do you understand what I
mean?

If you have the president's user account as a member of different
groups, you can give him different rights, and use a function or
whatever you want in the splash screen or whatever to determine what
objects the current user can use. If you got a copy of the form in the
Developer Handbook that mimics an Access db with all the containers
(for queries etc), then you could totally control what the users could
do, and it would look just like a normal Access DB, but they can only
use what you say they can.

This sort of makes sense. So the president will have different rights
than other users, because he is a member of more groups than other
users. So he'll have more menu choices. A new user? You would have
to create an account for this person to use the database if it's
secured. Or is it not? If it isn't the users/groups is worthless.
If you wanted to store all the name/address stuff in the database, you
could use CurrentUser to filter what the person sees in the db.

.