Title: Message
Yes.  And I usually disable the F11 keystroke by using an AUTOKEYS macro (yeah, a macro). 
 
Create a macro called AUTOKEYS, and add a line that has the Macro name of:
 
{f11}
 
And have it run Echo True, or point to a function that does nothing.
 
I do something like this, so F11 works for me, but no one else.

Public Function HandleF11()
On Error Resume Next
   
    Dim strNTUser As String
    strNTUser = GetNTUSER()
    
    If strNTUser = "toakes" Then
        DoCmd.SelectObject acTable, , True
    End If
   
End Function
 

Tom Oakes
Personal PC Consultants, Inc.
[EMAIL PROTECTED]
503.230.0911 (O)
402.968.6946 (C)
734.264.0911 (F)



From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Hoffman, Tobi K (DYS)
Sent: Thursday, September 29, 2005 9:11 AM
To: [email protected]
Subject: RE: [AccessDevelopers] Keeping users away from the tables!

You need to put error trapping EVERYWHERE!  Then you can at the least close the application entirely when it gets hit.  I picked up some code which I put into a module that writes to an error log (text file) when anything unexpected gets to my error trap routines:
 
Function Instrumented(Error As String)
    ' Comments:  Write all errors to a log file
    ' Parameters: Error -- string sent in error trap
    ' --------------------------------------------------
   
    On Error GoTo PROC_ERR
    
    Dim strLog As String
    Dim intFile As Integer
    Dim strPath As String
    Dim strMsg As String
   
    strLog = strPath & "DB_Error.Log"   ' set up the path you want, probably on network
LocalStart:
    intFile = FreeFile()
    If FileExists(strLog) Then
        Open strLog For Append As #intFile
    Else
        Open strLog For Output As #intFile
    End If
   
    Print #intFile, Now()        ' to give it a timestamp
    Print #intFile, pstrError
    Close intFile
   
PROC_EXIT:
    Exit Function
   
PROC_ERR:
    If Err = 76 Then    ' Path not found
        strLog = "c:\DB_Error.log"    ' use if your set-up path isn't found (for work at home!)
        Resume LocalStart
    End If
   
    MsgBox Err.Description
    Resume PROC_EXIT
End Function
Then call the function in the error trap section:
 
PROC_Err:
    Instrumented "FormName!CodeModuleName: " &  Error(Err)  ' concatenate any other useful data
 
You can do a lot with that, possibly concatenate the current user's name in the Instrumented code, add variables and values when you know where the errors are but not why they are happening, etc.
 
Tobi
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Cathy Jupp
Sent: Thursday, September 29, 2005 11:56 AM
To: [email protected]
Subject: RE: [AccessDevelopers] Keeping users away from the tables!

Thanks Tobi.  I do have a startup form so they don't see the tables in the normal course of events.  The problem is only really if they encounter a fatal error and click on End - that takes them stright to the database window.  Any suggestions for handling that gratefully received.
Cathy
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED]On Behalf Of Hoffman, Tobi K (DYS)
Sent: 29 September 2005 16:53
To: [email protected]
Subject: RE: [AccessDevelopers] Keeping users away from the tables!

How far you go will depend on 1) how trustworthy your people are, and 2) how sophisticated they are, as far as Access goes.  First of all, make sure to go to the Startup options, hide the database window and have a specific startup form.  You may want to disable the Shift-Key option before you compile the mde, then re-enable it to keep from blocking yourself out before you close.  (One way to go is to always copy your development file, make the Shift-Key change -- and others if needed -- and compile from there.)  There are other steps beyond that, some of which need to be used with great care so you maintain your own access to the front-end, but these will keep most casual users out.
 
Tobi
-----Original Message-----
From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of Cathy Jupp
Sent: Thursday, September 29, 2005 11:40 AM
To: [email protected]
Subject: RE: [AccessDevelopers] Keeping users away from the tables!

I'm in the process of moving my users from Access 2000 to 2003 and have purchased full licences for them all, as opposed to using the Runtime facility as we always have in the past.  This leaves me with the problem of how to stop the users opening tables and wreaking havoc following a fatal error.  It was never a problem with Runtime, because as soon as an error occurred the whole application closed down.  I've read on this list more than once that user-level security is best avoided, so I was wondering whether there was an easy way of preventing table access without using it.
I thought that creating an MDE file would be just the ticket, but that only protects the code, and as I copy the front end to the users' machines every time it is run, they can fiddle with that as  much as they like for all I care!
Thanks in advance
Cathy



Please zip all files prior to uploading to Files section.




SPONSORED LINKS
Microsoft access developer Microsoft access help Microsoft access database
Microsoft access training Microsoft access training course Microsoft access programming


YAHOO! GROUPS LINKS




Reply via email to