> On Fri, 27 Apr 2007 09:08:02 -0700, Adamfunchal <Adamfunc***@discussions.microsoft.com> wrote:
>
> >I have created a database with a password form where i put username and
> >password. That is working very well.
> >Now i have a question: its possible define permissions to users and
> >administrator, using this form, and not permissions of the database? If is
> >possible how can i do that?
>
> You'd need to add a table to your db that would store your permissions for each object and user, then query that table
> when the user successfully logs in.
>
> Here's a link that may help get you started. It deals with protecting a Form, but the basic concept and table design
> might be useful to study:
>
>  http://chazelleconsulting.com/Resources/Database/Password-protect_a_form.htm
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com
>

> On Mon, 30 Apr 2007 09:26:01 -0700, Adamfunchal <Adamfunc***@discussions.microsoft.com> wrote:
>
> >I've tried what says this link (
> >http://chazelleconsulting.com/Resources/Database/Password-protect_a_form.htm)
> >but does'nt work.
> >what is wrong??
>
> I don't really know what you mean by "doesn't work", but the link was intended to give some guidance on doing this, not
> really step by step instructions. Sorry about any confusion.
>
> >Now i have a question: its possible define permissions to users and
> >administrator, using this form, and not permissions of the database? If is
> >possible how can i do that?
>
> You can certainly store User/Group and Object permissions, but I can't really advise you how to do this, since I don't
> know your table structure. However, basically you'd do this:
>
> 1) Store Users
> 2) Store Groups
> 3) Store Objects
> 4) Store User-Group memberships (i.e. Which users belong to which groups).
> 5) Store User/Group - Object permissions (Which Groups can/cannot access whic objects)
>
> Which basically means you'd need 5 - 6 tables to do this. I'd also advise you to ONLY do this with Groups, as trying to
> keep track of User permissions can be tough.
>
> So when your login form authenticates a user, you'd (probably) store the UserID in a Global variable, or in a Table
> somewhere. Then, as your user attempted to open a Form or Report, you first (a) query the User/Group-Object permissions
> table for your specific User/Group and Object and then (b) allow or disallow the action, based on the results from that
> table.
>
> I'm not sure what you mean by "not permissions of the database". Can you explain a bit more on that?
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com
>

> On Wed, 2 May 2007 01:29:05 -0700, Adamfunchal <Adamfunc***@discussions.microsoft.com> wrote:
>
> >By "not permissions of the database" I mean: How I have 2 Databases and users
> >and permissions are not the same, I dont want set permissions on access
> >Tools»Security»User Permissions and workgroup.
> >I dont know if you understand but im Portuguese and my english isnt good,
> >sorry.
>
> Not a problem, just wanted to make sure that we understood each other.
>
> So you don't want to use ULS for this? In your case, since your not really concerned with data security but more with
> navigating in the database, ULS is a great choice (and you can have two different groups of users with ULS). ULS has
> builtin properties and methods which do exactly what you're trying to do - it tracks Users, Groups, User-Group
> Memberships, and User/Group Object permissions. Once you've setup ULS, you then can use the CurrentUser function to
> determine who is logged on, then use several custom function to determine if the CurrentUser has permissions to open a
> form, a report, view a query, etc etc ... or you can just let Access throw the default error message when they try to
> view an object for which they have no permission.
>
> However if you want to build your own login and navigation scheme, then perhaps this will work:
>
> http://www.databasedev.co.uk/login.html
>
> From here, you could add your Objects and ObjectPermissions tables, and then query those tables whenever a user tries to
> open a form ...
>
> >
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com
>

> On Wed, 2 May 2007 04:29:02 -0700, Adamfunchal <Adamfunc***@discussions.microsoft.com> wrote:
>
> >I've used that login form and its working well.
> >Now i want to know how i can set the users permissions based on taht form
> >and table.
>
> Do you have a table containing your Objects and Object Permissions? You'll have to do this, and without knowing your
> database structure it's impossible to advise you how to continue. If you can post the structure of the tables you're
> using to store Object names and Object-to-User/Group Permissions, then perhaps we can asist further.
>
> Basically, once the user logs in you would then simply query the tables to determine if the logged-in user has
> permission to open a form/report etc. So if you're storing the username in a variable named "CurrentUserName", you'd do
> something like this when the user tried to open the "Accounting" form:
>
> Dim rst As DAO.Recordset
> Set rst = Currentdb.OpenRecordset("SELECT * FROM MyPermissionsTable WHERE sTableName='Accounting' AND sUserName='" &
> CurrentUserName & "')"
>
> If Not(rst.EOF and rst.BOF) Then
>   If rst("bAllow") = True Then
>     '/allow the user to continue
>   Else
>     Msgbox "You don't have permission to open the Accounting form"
>   End If
> Else
>   MsgBox "You don't have permission to open the Accounting form"
> End If
>
> set rst = Nothing
>
> You'd need to change the table, column, and variable names to match those in your application, however that's the basic
> concept.
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com
>

>
>
>"Scott McDaniel" escreveu:
>
>> On Wed, 2 May 2007 04:29:02 -0700, Adamfunchal <Adamfunc***@discussions.microsoft.com> wrote:
>>
>> >I've used that login form and its working well.
>> >Now i want to know how i can set the users permissions based on taht form
>> >and table.
>>
>> Do you have a table containing your Objects and Object Permissions? You'll have to do this, and without knowing your
>> database structure it's impossible to advise you how to continue. If you can post the structure of the tables you're
>> using to store Object names and Object-to-User/Group Permissions, then perhaps we can asist further.
>>
>> Basically, once the user logs in you would then simply query the tables to determine if the logged-in user has
>> permission to open a form/report etc. So if you're storing the username in a variable named "CurrentUserName", you'd
do
>> something like this when the user tried to open the "Accounting" form:
>>
>> Dim rst As DAO.Recordset
>> Set rst = Currentdb.OpenRecordset("SELECT * FROM MyPermissionsTable WHERE sTableName='Accounting' AND sUserName='" &
>> CurrentUserName & "')"
>>
>> If Not(rst.EOF and rst.BOF) Then
>>   If rst("bAllow") = True Then
>>     '/allow the user to continue
>>   Else
>>     Msgbox "You don't have permission to open the Accounting form"
>>   End If
>> Else
>>   MsgBox "You don't have permission to open the Accounting form"
>> End If
>>
>> set rst = Nothing
>>
>> You'd need to change the table, column, and variable names to match those in your application, however that's the
basic
>> concept.
>>
>> Scott McDaniel
>> scott@takemeout_infotrakker.com
>> www.infotrakker.com
>>

> On Thu, 3 May 2007 02:54:00 -0700, Adamfunchal <Adamfunc***@discussions.microsoft.com> wrote:
>
> >My database structure is very simple:
> >You open the logon form (Its the same structure used in
> >http://www.databasedev.co.uk/login.html), then you see a form called
> >"Entrada" and there you select a button to another form called "Req", and you
> >work there.
> >I have a table called "tblEmployees" its where i save users and passwords
> >(its the same structure used in http://www.databasedev.co.uk/login.html).
> >I dont know if this help.
>
> Okay, good start, but you've still got to store information on which users can open which objects. Access stores all
> object names in MSysObjects, so you can use that if you like, but you've still got to store the "permissions"
>
> I'd suggest a table like this:
>
> tPermissions
> ---------------------------------
> sObjectName Text, 255 chars  (name of the Form, Report, etc)
> sUserName Text, 50 chars (name of the user)
> bCanOpen Yes/No field (True=User can open)
>
> I'd add a Unique Index with sObjectName and sUserName as the fields, but that's not required.
>
> Next, you'd need to populate that table. For example, let's say you have Users Sue, Sam, and Bob and you want to protect
> the Forms frmAccounting, frmEmployees, and frmAdmin
>
> tPermissions
> ---------------------------------
> sObjectName          sUserName            bCanOpen
> frmAccounting        Sue                           T
> frmAccounting        Sam                          T
> frmEmployees         Sam                          F
> frmEmployees         Bob                          T
> frmEmployees         Sue                          F
> frmAccounting        Bob                          F
> frmAdmin                Bob                          F
> frmAdmin                Sue                          T
> frmAdim                  Sam                         F
>
> Next, after logging in the users, you'd then add code to check the permissions for each user as they move through the
> database. Depending on how your db is strucutred, you might add this code in your Switchboard, or you might add it in
> the Load or Open event of the Form. I'd opt for the Open event, as it can be cancelled:
>
> '/in the code module for frmAccounting, for example
> Private Sub Form_Open(Cancel As Integer)
>   Cancel = UserCanOpen(Me.Name, gUserName)
> End Sub
>
> This assumes that you have a variable named "gUserName" which is storing the name of the currently logged in user ... if
> you don't then you'd need to change that to provide that username ... I haven't downloaded th sample from the link you
> provided, so I don't know how it's being handled but I'll leave that to you.
>
>
> Add this function to a Standard Module:
>
> Function UserCanOpen(ObjectName As String, UserName As STring) As boolean
>
> Dim rst As DAO.Recordset
>
> Set rst = Currentdb.OpenRecordset("SELECT bCanOpen FROM tPermissions WHERE sObjectName='" & ObjectName & "' AND
> sUserName='" & UserName & "')"
>
> If Not (rst.EOF and rst.BOF) Then
>   UserCanOpen = rst("bCanOpen")
> Else
>   '/if not record is found, allow the user to Open the object
>   '/Set this to False to disallow
>   UserCanOpen = True
> End If
>
> Set rst = Nothing
>
> End Function
>
>
> >
> >
> >"Scott McDaniel" escreveu:
> >
> >> On Wed, 2 May 2007 04:29:02 -0700, Adamfunchal <Adamfunc***@discussions.microsoft.com> wrote:
> >>
> >> >I've used that login form and its working well.
> >> >Now i want to know how i can set the users permissions based on taht form
> >> >and table.
> >>
> >> Do you have a table containing your Objects and Object Permissions? You'll have to do this, and without knowing your
> >> database structure it's impossible to advise you how to continue. If you can post the structure of the tables you're
> >> using to store Object names and Object-to-User/Group Permissions, then perhaps we can asist further.
> >>
> >> Basically, once the user logs in you would then simply query the tables to determine if the logged-in user has
> >> permission to open a form/report etc. So if you're storing the username in a variable named "CurrentUserName", you'd
> do
> >> something like this when the user tried to open the "Accounting" form:
> >>
> >> Dim rst As DAO.Recordset
> >> Set rst = Currentdb.OpenRecordset("SELECT * FROM MyPermissionsTable WHERE sTableName='Accounting' AND sUserName='" &
> >> CurrentUserName & "')"
> >>
> >> If Not(rst.EOF and rst.BOF) Then
> >>   If rst("bAllow") = True Then
> >>     '/allow the user to continue
> >>   Else
> >>     Msgbox "You don't have permission to open the Accounting form"
> >>   End If
> >> Else
> >>   MsgBox "You don't have permission to open the Accounting form"
> >> End If
> >>
> >> set rst = Nothing
> >>
> >> You'd need to change the table, column, and variable names to match those in your application, however that's the
> basic
> >> concept.
> >>
> >> Scott McDaniel
> >> scott@takemeout_infotrakker.com
> >> www.infotrakker.com
> >>
>
> Scott McDaniel
> scott@takemeout_infotrakker.com
> www.infotrakker.com
>