John,
By change, I don't mean within a single session, but over weeks/months/years, as new features are added and needs change. What started as simply an order tracking program (diff authority to add, approve, edit once approved), now tracks production, inventory, repairs, customer contacts, and more. With each new feature and type of authority, I add a new record to a table listing those authorities - tblAuthority (fields: Authority, AuthorityInfo). Then, to grant authority to an individual, I add a record to a separate table - tblUserRights (fields: UserName, Authority, DateAdded). I don't add a new field.
Rather than writing new code for a new pvar each time one is added, is there a way to generate the different pvars needed by looping through a recordset of tblAuthority?
Adam
--- In MS_Access_Professionals@yahoogroups.com, John Viescas <JohnV@...> wrote:
>
> Adam-
>
> Yes, in general Public variables (variables declared Public in a Standard
> module) stay set as long as the database is open. But they can get reset
> and reloaded back to their default values if there's an untrapped error.
> Note that the example I provided is not a Public variable because I used
> Dim.
>
> If the permissions can change while the user is running the app, then you
> should use DLookup every time. If you're OK with them remaining static
> with the values set when the app loads, then use my technique. You
> certainly can run code to load them all at startup, but my technique loads
> them on first reference. However, my technique won't work with Bit or
> Integer variables because those will both have a default value of 0 when
> loaded. You could use the Variant data type like this:
>
> Option Compare Database
> Option Explicit
> Dim pvarDeleteAllowed As Variant
>
> Public Function GetDeleteAuth() As Integer
>
> If IsEmpty(pvarDeleteAllowed) Then
> pvarDeleteAllowed = DLookup("DeleteAllowed", "ztblUserData")
> End If
> GetDeleteAuth = CInt(pvarDeleteAllowed)
>
> End Function
>
> A Variant data type can hold any type of data (including Null) and is
> "Empty" when first defined.
>
> Note that you can also add a filter as the third parameter in DLookup to
> fetch the data for a specific user.
>
> John Viescas, Author
> Microsoft Access 2010 Inside Out
> Microsoft Access 2007 Inside Out
> Microsoft Access 2003 Inside Out
> Building Microsoft Access Applications
> SQL Queries for Mere Mortals
> http://www.viescas.com/
> (Paris, France)
>
>
>
> -----Original Message-----
> From: AdamF <runuphillracing@...>
> Reply-To: <MS_Access_Professionals@yahoogroups.com>
> Date: Tuesday, November 27, 2012 10:52 PM
> To: <MS_Access_Professionals@yahoogroups.com>
> Subject: Re: [MS_AccessPros] Tracking user profile
>
> John,
>
> So are public variables then kept (assuming the front end) and accessible
> as long as the user is logged in? So that if I have a bunch of boolean
> variables (e.g. OrderApprove), I can the use code like
> If OrderApprove = True then
> code to hide, lock, enable different fields
> End If
>
> A One issue with the approach of writing separate "wrapper" functions is
> that the different types of permissions do change. I maintain the list of
> permissions in a table tblPermissions. Is there a way to generate these
> variables from the list in that table?
>
> Adam
>
> --- In MS_Access_Professionals@yahoogroups.com, John Viescas <JohnV@>
> wrote:
> >
> > Adam-
> >
> > I prefer to use a table in combination with Public variables to do this.
> > It's a known fact that stuff stored in memory can "disappear" of there's
> > an error. And a "hidden" form may not always be hidden and is slower to
> > reference.
> >
> > Here's what I do in a Standard module:
> >
> > Option Compare Database
> > Option Explicit
> >
> > Dim pstrLoginName As String
> >
> > Public Function GetUser() As String
> >
> > If Len(pstrLoginName) = 0 Then
> > pstrLoginName = DLookup("UserName", "ztblUserData")
> > End If
> >
> > GetUser = pstrLoginName
> >
> > End Function
> >
> > Of course, this assume you stored the user name at login in ztblUserData.
> >
> > You can write as many "wrapper" functions as you like to grab / populate
> > the module variables.
> >
> > John Viescas, Author
> > Microsoft Access 2010 Inside Out
> > Microsoft Access 2007 Inside Out
> > Microsoft Access 2003 Inside Out
> > Building Microsoft Access Applications
> > SQL Queries for Mere Mortals
> > http://www.viescas.com/
> > (Paris, France)
> >
> >
> >
> > -----Original Message-----
> > From: AdamF <runuphillracing@>
> > Reply-To: <MS_Access_Professionals@yahoogroups.com>
> > Date: Tuesday, November 27, 2012 9:56 PM
> > To: <MS_Access_Professionals@yahoogroups.com>
> > Subject: [MS_AccessPros] Tracking user profile
> >
> > Currently, when a user logs in, I open an unbound, hidden form, and write
> > their profile info (from a table using their login name) to that form
> > (frmUser). I then refer to that form on numerous pages to customize the
> > view and edit/delete/add authorities. I did this because it seems a lot
> > quicker to look up in a form than using dlookup to tblUserProfile.
> >
> > Is there a better way?
> >
> > I've thought about creating a set of two local (front end) tables with
> > this info, in lieu of an unbound form.
> >
> > I think I recall somewhere about tracking properties in VB. I have no
> >idea
> > how that works.
> >
> > Adam
> > Denver, CO
> >
> >
> >
> > ------------------------------------
> >
> > Yahoo! Groups Links
> >
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
| Reply via web post | Reply to sender | Reply to group | Start a New Topic | Messages in this topic (5) |
Tidak ada komentar:
Posting Komentar