Database of Messages

[GCC Consulting]

> -----Original Message-----
> From: filepro-list-bounces at lists.celestial.com 
> [mailto:filepro-list-bounces at lists.celestial.com] On Behalf 
> Of Fairlight
> Sent: Monday, August 09, 2004 6:12 PM
> To: filepro-list at lists.celestial.com
> Subject: Re: Database of Messages
> 
> Y'all catch dis heeyah?  Rod Caddy been jivin' 'bout like:
> > Windows 98/XP/2000/2003/whatever is next.  Filepro 5.0
> > 
> > I am trying to come up with a way to create a database of 
> messages to 
> > use in msgbox and errbox and then call that database when certain 
> > events happen.  Example would be:  We have a login 
> procedure for all 
> > users of our towing product.  The user information is kept in a 
> > datbase and each is given a designation of user, 
> supervisor, or super 
> > user.  We can easily determine who they are and their designation.  
> > Without creating extra filepro processes or having a user have 
> > multiple sessions of filepro running for one login, I want 
> to be able 
> > to capture which menu selection they select and then 
> determine if they 
> > have access to that area of the program.  This can be 
> helpful because 
> > I have literally put new passwords on back office menus 5 
> times in one 
> > day.  If I can create this where it is somewhat generic then it 
> > becomes more functional across other products I am working 
> on.  Any ideas would be greatly appreciated.
> 
> I don't quite understand the breakpoint at which you wish to 
> insert such code.  Do you want to do it right after they 
> select at runmenu and before they hit -any- instance of 
> *clerk or *report, or do you want to handle it as they're 
> coming into processing?
> 
> mark->
If you are trying to control access by user, create a user profile file.  This
file should only be accessed by the system administrator. Set yes/no fields for
various levels of access.

You can use the users login name and create an array to read in the permissions
for the file being accessed.  Run @once processing to get this information and
set the access criteria.  Use @key commands to control those functions.

You can even build this logic into reports. Use dummy fields where information
may not be available to all users. Or you could create an input process which
will call the "proper" report format based on the users access level.

Richard Kreiss
GCC Consulting