Group Permission unsolicted changes

[TESA0_4]

Hi,

I have an application that has been developed in Access 2000 format using
Access 2003 that is being run exclusively in a WindowsXP/Access2003
environment.

The database is split and secured. Some users have personal usernames but
most users log in using a username called 'READ' that 'effectively' provides
read-only access to the application. I say 'effectively' because READ does
have higher permission to certain tables to write log records that are not
apparent to the user.

I have two back end databases, one that holds the live production data and
another that serves as a 'training database'. When users log in to the front
end they select the database they want and code automatically unlinks/links
tables as appropriate.

There is one exception. One table, called tblPers which holds user
information and names, is always linked to the front end from the live back
end. This configuration was set up so that any personnel changes made in the
live database are immediately available when accessing the live or training
database.

All permissions are set up against Groups and all usernames are members of
one or more Groups.

The Front End security for the ReadOnly Group is set up so that the Group
has administrator permission to all Back End tables. I found this level of
permission was required to enable the unlinking/linking to occur between the
two back end databases. Permission for the ReadOnly Group on the two Back End
databases is suitably limited.

Now for the problem. Every now and again a user advises that they cannot log
into the system using the READ username. The problem is invariably caused by
the ReadOnly Group 'losing' its front end administrator permission to
tblPers. The permission 'drops' to read only which causes the log in to fail.

I am 100% confident that no one with administrator access is tinkering with
the Permissions.

Can anyone explain what might be is causing the unsolicited change to the
Permission level of the ReadOnly Group?

Thanks in anticipation of any assistance you can offer.

 

[Joan Wild]

How are you refreshing the links? Do you drop and recreate the links?
If so, what are the permissions in the FE for new tables?

Since this is happening for the only table that is linked to a different
BE, I'd examine the code to see what it's doing differently for this one
table.

Joan Wild

 

[TESA0_4]

Hi Joan,

Thanks for taking the time to respond to my query. I consider myself to be a
persistent ameteur who writes some code and takes advanatage of great code
available on the web.

The table linking and unlinking in my application uses the fRefreshLinks
Function written be Dev Ashish. However, near the end of his function and
after it has done all necessary unlinking and linking, I have inserted the
following code:
If LiveBE = False Then
DoCmd.DeleteObject acTable, "tblPers"
DoCmd.TransferDatabase acLink, "Microsoft Access", _
DLookup("LiveBEFilePath", "tblSysConfig") & _
DLookup("LiveBEName", "tblSysConfig"), _
acTable, "tblPers", "tblPers"
End If
LiveBE is a Public Variable set by the user and records which BE they want
to link to. LiveBE=False means the TrainBE.

I assume that this code and the FE persmission level for New Tables were
combining to cause my problem. The permission for new tables was not set at
Administer.

I think you have solved my problem!!

Thank you.