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)
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
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
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
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.
YAHOO! GROUPS LINKS
