might have to control user view..?

[sparks]

Just died a little db of our time sheets and think that I might have a
problem.
I just put a pulldown of the employees and a week that they are
entering time. Then in a continuous list in a sub form they have
pulldowns for dept, and job...field for hrs worked and comments.

simple but I was thinking or one future problem. They have no concerns
of who does what. I can view and even edit other peoples time...which
is ok. I will be submitting quartly reports of this information BUT
what of someone else viewing and editing another persons hrs.
I asked the mgr and they said no problems, everyone should know what
everyone else is working on anyway.
BUT in the future I can see this as having to be changed in some way.
How could I make this so that bob can only enter/edit his time ...etc
I thought of seperate databases for each person...would this be a
problem on a one to many with autoid's to import/append the data from
each person into one database for reports?
Start autoid at 1000,5000,10000 for each person to make sure there is
no overlap ??? Kinda sounds iffey

Would be cool for them to put in a number on startup and only
create/see records associated with that access number...easy to get
around by looking in a table for the numbers but what the heck.
I have tought of a lot of things nothing sounds all that great, and
just more work for me later.

Thanks big time for any ideas or comments....has anyone done this
before..

[Arno R]

Comments inline

"sparks" <sp****@somewhere.comschreef in bericht news:j6********************************@4ax.com...

<snipped>

How could I make this so that bob can only enter/edit his time ...etc
I thought of seperate databases for each person...would this be a
problem on a one to many with autoid's to import/append the data from
each person into one database for reports?
Start autoid at 1000,5000,10000 for each person to make sure there is
no overlap ??? Kinda sounds iffey

NO you should NEVER create databases for each person.
Just identify who's logged on and limit the query's/forms/records to that personID.
You could identify the user by means of userlevel security (not that easy if this is new for you...)
You could also possibly identify the user by means of the Windows logon.
Code for this can be found by Googling on 'fOSUserName'

Would be cool for them to put in a number on startup and only
create/see records associated with that access number...easy to get
around by looking in a table for the numbers but what the heck.
I have tought of a lot of things nothing sounds all that great, and
just more work for me later.

Thanks big time for any ideas or comments....has anyone done this
before..

Identify the user as explained above or let the user identify his/herself by choosing an entry in a combobox.
Choose what suits your needs best.
Once you 'know' the personID you only give them access to their own records.
Post back if you need more help.

Arno R

[sparks]

Thanks I will have to look into this.
Have you read any books that deal with this kind of thing?

Sparks
On Mon, 15 Jan 2007 13:22:50 +0100, "Arno R"
<ar***********@tiscali.nlwrote:

>Comments inline

"sparks" <sp****@somewhere.comschreef in bericht news:j6********************************@4ax.com...

<snipped>

>How could I make this so that bob can only enter/edit his time ...etc
I thought of seperate databases for each person...would this be a
problem on a one to many with autoid's to import/append the data from
each person into one database for reports?
Start autoid at 1000,5000,10000 for each person to make sure there is
no overlap ??? Kinda sounds iffey

NO you should NEVER create databases for each person.
Just identify who's logged on and limit the query's/forms/records to that personID.
You could identify the user by means of userlevel security (not that easy if this is new for you...)
You could also possibly identify the user by means of the Windows logon.
Code for this can be found by Googling on 'fOSUserName'

>Would be cool for them to put in a number on startup and only
create/see records associated with that access number...easy to get
around by looking in a table for the numbers but what the heck.
I have tought of a lot of things nothing sounds all that great, and
just more work for me later.

Thanks big time for any ideas or comments....has anyone done this
before..

Identify the user as explained above or let the user identify his/herself by choosing an entry in a combobox.
Choose what suits your needs best.
Once you 'know' the personID you only give them access to their own records.
Post back if you need more help.

Arno R