>> Typically what happens is that everything works OK, then one day I get a
>> call to say that an error has occurred 'No permission to access table xxx'.
>> I log on remotely using the app and get the same error. I go into IBExpert
>> and look at the permissions and they are all there. I delete them,
>> reinstate them, re-start the app and everything is OK.

Paul,

I saw such a behaviour in 2 scenarios; both of which do not seem to
apply to your situation; but you can never be too sure :)

Maybe someone will jump in with additional scenarios later.

a.) make sure that whatever is logging you into the database is always
doing so as "PAUL" (all uppercase) and not as "Paul".
There has been or still is a bug in 1.5 that will assign to you the
"PUBLIC" user permissions if your log-in name is not all uppercase.

Most users will never find out, because they are lavishly giving
nearly all permissions to "PUBLIC"; but if you do block the PUBLIC
user (probably a good idea), then you will get "No permission..."


b.) a member of our usergroup was forced to share his database with a
3rd party software which - so we found out later - has been always
working in "table snapshot" isolation. I don't remember the details,
and if I did I probably would not understand them, but the effect was
pretty much the same:
Tables were there, but could not be accessed by anybody else in the
network until the application that created the table was shut down
(!). Obviously they also did not care too much about terminating
transactions.

>> The database has two logins SYSDBA and PAUL. All user security is handled
>> within the client app which logs in as PAUL. There are no roles defined

It is by the way fairly easy to create a mapping "windows
user/application user/database user". That way you would not only have
user "PAUL" logged in, and could make use of some wonderful
monitoring/logging functions.


ciao,
André