Multi User Login

[Deepak]

Hi All

I have created a user login form, where the users select his user name and
then enter password and click go. On verifying the contents entered user is
allowed to enter into database and Switchboard is displayed.

The user upon entering can add insurance policies he has done and update
premium paids and then run some queries to check policy lapsed, premium due
etc.

Now i want is that user logged in should be able to see only the data he has
entered.

Basically the need is that when the enter new policy data in master table a
field "user id" is automatically updated to the user logged in.

I wanted to know how to automatically to do this.

any help would be greatly appreciated.

Thanks
Deepak

 

[Arvin Meyer MVP]

If you are capturing the user's login name when you write the data, you can
easily use that to create a query so that user can only see his own data.
Base you form on the query. Access will resolve user created public
functions in query criteria, so just create a function to capture the user
login name and use that as query criteria.

 

[Keith Wilby]

Hi All

I have created a user login form, where the users select his user name and
then enter password and click go. On verifying the contents entered user
is
allowed to enter into database and Switchboard is displayed.

The user upon entering can add insurance policies he has done and update
premium paids and then run some queries to check policy lapsed, premium
due
etc.

Now i want is that user logged in should be able to see only the data he
has
entered.

Basically the need is that when the enter new policy data in master table
a
field "user id" is automatically updated to the user logged in.

I wanted to know how to automatically to do this.

any help would be greatly appreciated.

You can but I'm afraid just about any "roll your own" security will be very
easy to defeat by anyone with a modicum of Access knowledge. Can you take
that hit? If you can then you can get the user's network name by using
this:

http://www.databasedev.co.uk/network_user.html

Store that name against each record as it is created and filter for it when
the main for opens.

You can implement the built-in user-level security provided that you're sure
there are no "determined hackers" on your horizon, it will certainly keep
the "busy-bodies" out.

Keith.
www.keithwilby.co.uk

 

[Deepak]

Arvin thanks for your help.

Kindly help me how to capture the user's login name

 

[Arvin Meyer MVP]

I use the code at:

http://www.mvps.org/access/api/api0008.htm

 

[Arvin Meyer MVP]

You can but I'm afraid just about any "roll your own" security will be
very easy to defeat by anyone with a modicum of Access knowledge. Can you
take that hit? If you can then you can get the user's network name by
using this:

http://www.databasedev.co.uk/network_user.html

Store that name against each record as it is created and filter for it
when the main for opens.

You can implement the built-in user-level security provided that you're
sure there are no "determined hackers" on your horizon, it will certainly
keep the "busy-bodies" out.

The new database version for Access 2007 (accdb) does not support user-level
security, so "roll your own" is the only option. Either can be effective
against anyone but determined hackers, but the data itself is only maximally
secured with a server based engine, like SQL-Server. As it has been said
that locks only keep out honest people, so it is with security. A truly
committed hacker will gain access to your data. My rule of thumb is to try
and keep the good guys in (choose your employees carefully, and treat them
well), and the bad guys out (create effective locks, both physical and
computer based, and don't hire without background checks)

 

[Keith Wilby]

The new database version for Access 2007 (accdb) does not support
user-level security, so "roll your own" is the only option.

If you retain the mdb format then ULS is still supported ... but I'm sure
you knew that Arvin <g>.

Keith.

 

[Arvin Meyer MVP]

If you retain the mdb format then ULS is still supported ... but I'm sure
you knew that Arvin <g>.

Of course, which is why I qualified the statement with accdb, as shown
above. In fact, the compiled version (accde) also does not support ULS. Both
do, however support a password. Sensitive data should still be protected by
a server based engine like SQL-Server. There are instances where data in an
MDB can be protected by a server, and those include using Access on a web
server or a Terminal Server, where permissions can be limited to what is
returned by a query.

 

[Keith Wilby]

Of course, which is why I qualified the statement with accdb, as shown
above.

I was just joshing with you, which is why I qualified the statement with
<g>, as shown above.