VBA Disable Escape Key (ESC), Interrupting Queries

[Stormin]

Hi all,

I have a piece of code in one of my databases that runs 22 queries to import, delete, and append external data to the local tables. This process--due to one or two large queries in the source database--takes around 2-3 minutes, which is not a problem in itself.
However, I have noticed that a user can press the ESC key when the queries are running which triggers "Error 3059: Operation canceled by user." for the current query. What's even worse is that pressing the ESC key in another application e.g. Excel will also trigger this behaviour in Access even though the window is not active. I have tested this with both dual-screen and single-screen setups.
The queries are running through db.Execute

Edit: I forgot to mention that a simple "Please Wait" Access (not vba) form is loaded for the duration of the procedure.

Is there any way to disable the ESC key while the import code runs so that queries cannot be canceled? I've tried turning off the "EnableSpecialKeys" property but I still observe the same behaviour.

Cheers

 

[isladogs]

You can remap most keys to something innocuous or disable it whilst the procedure is running then restore it's normal usage afterwards. There are exceptions that can't be altered e.g Windows key, but Esc should be ok for this.

This will disable the Esc key for the lifetime of the form

Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)

Select Case KeyCode

Case vbKeyEscape
   'Esc pressed - don't allow it
    KeyCode = 0

Case Else
   'no code here

End Select

End Sub

Note : you must also set Key Preview to Yes in the form properties

If you want to disable just whilst the procedure is running, adapt the code so its called at the start of the procedure instead

 

[Stormin]

Hi ridders,

Interesting that it might be taking the keys through the "Please Wait" form (which I forgot to mention in the original post--now edited) so I have tried your solution. The database is pre-release so currently the code is called manually and not from a form itself. Here are the steps I have taken:

1. Added your code exactly into the code behind the "Please Wait" form that loads before the queries are called
2. Changed the form property "Key Preview" to Yes

Unfortunately when running the import and keeping the Access screen active I can keep hitting ESC and cancelling queries as they run. I've tested with the application property "AllowSpecialKeys" set to both True and False with no change in behaviour.

Any other ideas?

 

[Stormin]

I have just quickly created a form with a button that triggers the code and applied the same techniques as in the above post. No change to behaviour.

 

[el.alcalde]

Do you use sub forms on your main form?

 

[Stormin]

I have just tested with not loading the "Please Wait" form, so that the loop to execute the queries is happening without any forms involved at all. Same behaviour.

 

[Stormin]

I've done some more testing and the ESC key is definitely being picked up during the db.Execute method and canceling the execution.

 

[isladogs]

It's worked for me in the past.
Can you upload your db and I'll test it later today

UPDATE:
You could also have a look at the attached zip file containing an example database where almost all keys & keyboard combinations can be disabled.
Not specifically for your situation but may help.
It includes 2 Word docs with further explanations

 

[Stormin]

I have created a sample database that can replicate this behaviour with the ESC key. I'm using Access 2016.

Pressing the ESC key while the SQL is executing / running will throw an error to cancel the SQL statement.

See attached.

 

[Frothingslosh]

I was going to say you need to use an AutoKeys macro, but it appears neither {ESC} nor {ESCAPE} are accepted in the macro. Your issue could be because your form might be losing focus while the queries run, which would prevent the KeyDown event from triggering.

 

[The_Doc_Man]

After researching this a bit online, I realized you are not alone. This has been reported in other forums. It seems that in the transition from Ac2003 to Ac2007 this problem cropped up and may be related to the overall changes in Office. But it ALSO could be due to changes in Windows.

I don't think I want to play with this too much myself because of the implications, but you might try doing a web search (not forum search) for "disable windows escape key" which possibly would include a registry edit. It is possible for you to make registry changes from Access, which you CAN look up with a forum search.

I found a thread on the social.msdn site indicating that this behavior has been brought to the attention of the Microsoft developers, but no solution has been announced yet and it may be that this is not a bug but rather is intended behavior, a sort of safety net for runaway tasks.

If you were lucky and were on Windows 10, you might accidentally (and luckily) find yourself in the situation that I have ALSO seen when researching this, where Win10 sometimes breaks the Escape key, which is then hard as Hell to get back. Seriously, it seems that some weird juju is transpiring with escape keys and perhaps there is a diverse set of opinions on what behavior is best.

Philosophically, I can understand the desire to NEVER have a situation where you can't tell your computer "SHUT UP AND SIT STILL" when it gets crazy. (Anyone with energetic grandkids understands that one.) Watching Windows evolve over the years, I have seen the continuing attempt to make it a non-stop system such as the Tandem Non-Stop O/S and OpenVMS, both of which have extraordinary stability. Having that ESC key do what it does makes it possible to stop runaway processes without forcing a power-down reboot. We all should understand what THAT does and what it risks for running processes.

I can also understand the conflicting desire to be able to stop interruptions for a few minutes when a critical & complex update is under way. Again, that is actually not inconsistent with a non-stop philosophy at the O/S level.

I can see the need to protect yourself when that long update runs. My question is whether you might be able to us transaction methods (BEGIN/COMMIT) to make your changes more robust. However, if you reach the COMMIT phase and the ESC key is hit at that point, I would suspect that the damage would still occur.

If you do the searches and find something that works, it might be beneficial to the forum community to see what you did, at least in overview. But I am sad to report that I have no immediate solution for you, just some suggested searches.

 

[isladogs]

All sorted.
As I had done this myself some years ago, I was thrown at first by it not working when I tested it.
It works now! It threw up some interesting issues

A few changes made:

First of all your test SQL was incorrect

s = "INSERT INTO Table1 ( a ) SELECT Table1.a FROM Table1;"

This produces a huge number of records rather than the number set in your constant value (1000 or 5000)
Replacement SQL which adds the correct number in a MUCH shorter time!

s = "INSERT INTO Table1 ( a ) SELECT 'a' AS a;"

Can you see how this is different and why it matters ....

Doing this also means you no longer need to populate your table with one record after emptying it!

Next I've removed your If...End If loop as that was allowing the Esc key to run even though it was supposedly disabled.
That's an interesting example whereby adding code to monitor events is actually affecting them!

I've also added error handling for err 3059 (both methods) & 2501 (RunSQL only)

After doing those changes, the functions cannot be interrupted using Esc
Of course you may be able to interrupt the code by other means but you should be able to fix them as well if its an issue. However, in my view there should always be a way of interrupting procedures if necessary.

So you can see what is happening, I've added captions to the form to show progress.

I also added code to time the functions
As I expected Execute method is much quicker than RunSQL
To add 5000 records took 12s for Execute & 36s for RunSQL ...on my 6 year old & slow PC.
Good to have confirmation that CurrentDB.Execute is more efficient

I also changed the button code to call the functions using VBA instead of macros.
Forgot to change the button captions.

Modified version attached - do try to break it - let me know how you get on

For info, whilst you can edit the registry to disable combinations of keys such as Ctrl+Alt+Del, its not necessary for single keys like Esc

 

[Stormin]

Hi ridders,

Thanks for tackling this for me!

Unfortunately I have managed to break your method, it must be my uncanny ability to break everything

I have reattached the sample database with my changes.

The first point of the SQL... actually I designed it exactly like that to create a slow query. I don't know how people usually make artificially slow queries in Access (still none-the-wiser after Googling) so thought doubling a table would do. It is confusing if you look at the code because the first statement I wrote was exactly yours to add just one record, but the query runs too fast for a human to have a decent chance to interrupt them. Because I made the sample db quickly it didn't bother go back and change the variable names or constant values to make this clear, sorry!

The IF check I feel is the same as your error handler, I just had mine embedded since I capture the error num/desc and write it to the import log. I have two of these actually, one for the GetSQL part (I supply the query name and retrieve the SQL in order to use db.Execute) and another for actually running the SQL.

I agree that there should still (always) be a way to cause a break in the code, I'm just trying to stop it from happening with such a common key as ESC--I prefer CTRL+BREAK definitely.

See the attached database and see if you can remove the ESC key's functionality for cancelling a RunSQL or Execute. On my computer the query slows to a nice pace after pass #15 where you can easily see the effect of the ESC on cancelling the query.

Let me know your thoughts!

Cheers again,
Stormin

 

[isladogs]

Hi ridders,

Thanks for tackling this for me!

Unfortunately I have managed to break your method, it must be my uncanny ability to break everything

I have reattached the sample database with my changes.

The first point of the SQL... actually I designed it exactly like that to create a slow query. I don't know how people usually make artificially slow queries in Access (still none-the-wiser after Googling) so thought doubling a table would do. It is confusing if you look at the code because the first statement I wrote was exactly yours to add just one record, but the query runs too fast for a human to have a decent chance to interrupt them. Because I made the sample db quickly it didn't bother go back and change the variable names or constant values to make this clear, sorry!

The IF check I feel is the same as your error handler, I just had mine embedded since I capture the error num/desc and write it to the import log. I have two of these actually, one for the GetSQL part (I supply the query name and retrieve the SQL in order to use db.Execute) and another for actually running the SQL.

I agree that there should still (always) be a way to cause a break in the code, I'm just trying to stop it from happening with such a common key as ESC--I prefer CTRL+BREAK definitely.

See the attached database and see if you can remove the ESC key's functionality for cancelling a RunSQL or Execute. On my computer the query slows to a nice pace after pass #15 where you can easily see the effect of the ESC on cancelling the query.

Let me know your thoughts!

Cheers again,
Stormin

Did you manage to break it using EXACTLY my example database without changing it? If so, what exactly did you do?
I tested it repeatedly & failed to break it?

I don't see the point of creating a 'slow query' as you call it.
It seems like you are creating an artificial situation for the sake of it.
As for 'a nice pace', I'd describe that as the procedure slows to a complete crawl after pass 18

Your IF check was definitely NOT the same as my error handling.
We both know that pressing & holding Esc causes an error (3059).
Using RunSQL also triggers err 2051 when Esc held
Your code allows that error to stop execution - the exact opposite of what you wanted.
Using error handling & Resume Next tells the code to ignore the error and continue the procedure.

I've found a couple of minor code errors in the db you uploaded but neither were relevant to fixing your issue

I agree I can interrupt your code but that's easily fixed.
I added the line DoEvents in both procedures purely so the form 'progress captions' could update.
Comment both of those out which means the caption won't update.
You also won't see your end message

Now look at your Debug. lines in the Immediate window
For example

1      30/04/2018 18:30:01 
 2      30/04/2018 18:30:01 
 3      30/04/2018 18:30:01 
 4      30/04/2018 18:30:01 
 5      30/04/2018 18:30:01 
 6      30/04/2018 18:30:01 
 7      30/04/2018 18:30:01 
 8      30/04/2018 18:30:02 
 9      30/04/2018 18:30:02 
 10      30/04/2018 18:30:02 
 11      30/04/2018 18:30:02 
 12      30/04/2018 18:30:02 
 13      30/04/2018 18:30:02 
 14      30/04/2018 18:30:02 
 15      30/04/2018 18:30:02 
 16      30/04/2018 18:30:02 
 16      3059: Operation canceled by user.
 17      30/04/2018 18:30:02 
 18      30/04/2018 18:30:03 
 18      3059: Operation canceled by user.
 19      30/04/2018 18:30:03 
 19      3059: Operation canceled by user.
 20      30/04/2018 18:30:03 
 20      3059: Operation canceled by user.

As you can see the error is triggered but the code continues & completes
That's using Execute - with RunSQL it shows err 2501 but still completes.

I accept you may get fewer records but as already stated this isn't in my view a realistic setup

Rather than try to work on an artificial test database, I would prefer to test the real thing.
However, if you have procedures where code runs at a crawl, I suggest you first look at ways of improving the code so it runs faster

Also bearing in mind that using Ctrl+Break to interrupt procedures is just as well known as pressing & holding Esc, I think there is a limit to the amount of time its worth spending on this.

 

[Stormin]

Thanks ridders, I appreciate your detailed answer.

I didn't spend much time trying to break your db exactly as it was since it doesn't reflect the situation I'm trying to solve. However, starting from an empty table each time and running both methods at 1000 counts, I was able to interrupt a few of the queries and end up with only 993 and 994 records added for RunSQL and Execute respectively. Most of them complete too fast for the ESC key (tapped, not held) to be activated in the middle of execution.

I think you are already aware of this because of the quote below, and I perhaps suspect that we are trying to solve different problems:

I accept you may get fewer records

This is the behaviour I am trying to prevent via the ESC key. The code runs fine through to completion but the queries that are cancelled are critical to building the local tables which all the reporting is based. The MsgBox lines which "interrupt" the code in the first sample database are there to highlight when the problem occurs and are not themselves the problem I am trying to solve.

Maybe CTRL+BREAK is as well-known as ESC, but when pressing CTRL+BREAK you are intending to interrupt the current process. If you have the import running in the background in Access and then are working in Excel, is it not fair to think that the ESC key is much more likely to be innocently used (e.g. cancelling a cell input) than CTRL+BREAK?

The 'slow' queries are unavoidable. The main two are:
1. the external data import over the network, with the source (external) query taking at least a minute or so due to the complex work it performs on the external database. This cannot be changed, and would indeed be a subject in itself.
2. the final table append that is built using a few dozen queries - again this is a complex operation by its nature and takes a minute or so to process. There are two of these.

See attached Excel file for the refreshlog output of both a successful and cancelled import to see this more clearly.

Also see below for the exact code that handles the running of the queries if you're interested to dig through:

''''...
''''...
    
    'Add queries to run to the array
    ReDim aQ(1 To 22, 1 To 5)
    'aQ(x, 1): Query name
    'aQ(x, 2): Query run time
    'aQ(x, 3): WasSuccessful
    'aQ(x, 4): Error Description (if applicable)
    'aQ(x, 5): Table affected (if applicable)
        'Repopulate the UVOdb table updates
        aQ(1, 1) = "qdelUVOdbTableUpdates"
        aQ(2, 1) = "qappUVOdbTableUpdates"
        aQ(2, 5) = "zstblUVOdb_TableUpdates"
''''''''etc.....
''''''''...
''''''''...


    'Run the queries
    On Error Resume Next
    For i = LBound(aQ, 1) To UBound(aQ, 1)
        sRunOrder = i & " of " & UBound(aQ, 1)
        If Len(CStr(aQ(i, 1))) > 0 Then
            'Get the query SQL
            sSQL = ""
            sSQL = GetQuerySQL(CStr(aQ(i, 1)))
            'Check if getting query SQL was successful
            If Err Then
                'Record failure and error message, clear error
                aQ(i, 3) = False
                aQ(i, 4) = "[GetSQL] Error " & Err.Number & ": " & Err.Description
                Err.Clear
            Else
                'Run the query and time it
                t_bef = Timer
                db.Execute sSQL, dbFailOnError
                lRCount = db.RecordsAffected
                t_aft = Timer
                'Check if running query SQL was successful
                If Err Then
                    'Record failure and error message, clear error
                    aQ(i, 3) = False
                    aQ(i, 4) = "[Execute] Error " & Err.Number & ": " & Err.Description
                    Err.Clear
                Else
                    'Record success
                    aQ(i, 3) = True
                End If
            End If
            'Save the runtime
            aQ(i, 2) = t_aft - t_bef
            t_tot = t_tot + aQ(i, 2)
            t_bef = 0
            t_aft = 0
            'Keep track of total successes
            lSCount = lSCount + aQ(i, 3)
            'Save the log data to the refresh log detail table
            RefreshLogDetail_InsertNewRecord _
                RefreshID:=lRefreshID, _
                RunningOrder:=sRunOrder, _
                QueryName:=CStr(aQ(i, 1)), _
                DurationInSeconds:=CSng(aQ(i, 2)), _
                WasSuccessful:=CBool(aQ(i, 3)), _
                ErrorDescription:=CStr(aQ(i, 4))
            'If there is a table updated, record the
            ' update time in zhtblTableUpdates
            If aQ(i, 5) <> "" And aQ(i, 3) = True Then
                InsertTableImportDate _
                    ImportedTableName:=CStr(aQ(i, 5)), _
                    RecordsAffected:=lRCount
            End If
            'Add to the finish message
            sMsgTimer = FormatTimer( _
                StartTimer:=0, _
                EndTimer:=CSng(aQ(i, 2)), _
                OutputFormat:=fMinsAndSecsShort)
            sMsgFull = _
                sMsgFull & vbNewLine & _
                CStr(aQ(i, 1)) & " = " & sMsgTimer & IIf(aQ(i, 3), "", " (Fail)")
        End If
    Next i
    On Error GoTo -1
    On Error GoTo 0 'pre-production with little error handling
    
''''...
''''...

I agree it would be much easier to have us work together on the actual database, but as usual that's not possible. I'll do my best to share what I can, however.

 

[isladogs]

I've had a look at your logfile and believe we are trying to deal with the same problem

My point was that your sample database wasn't a realistic test.
The ideal would be to be able to test your actual setup but in the absence of that I've created a simple test database.

It has 1 table with 2.6 million records (UK postcodes) and I've added a boolean field so I can set all records true or false.
With no interruptions it takes 14 seconds on my PC which is long enough to test the issue

I've used similar code to that in my first attempt and remapped Esc to 0 using the Form KeyDown event (as in post #2)

You MAY be pleased to know that I CAN replicate your situation and interrupt the code by pressing Esc in Access

However your comment about Excel intrigued me as I thought any key presses would only affect the program they were used in.
I tested pressing Esc repeatedly in Excel whilst the Access code was running.
SUCCESS - It had no effect on the Access procedure so that seems to be one less thing to worry about.

So then I went back to Access and added a please wait form which I set as Popup & Modal with no control box & no buttons.
I then had this to open when the procedure started & close automatically when done
I also maximised it whilst in use so it couldn't be missed by end users
FAIL - However it doesn't stop a determined user who insists on pressing Esc. SIGH!

Finally I altered the registry to disable the Esc key completely
SUCCESS - the procedure ran without interruption

If that's not too drastic a step for you, you could download a free utility called SharpKeys which will do that for you
If you like the idea, I can supply code to do the registry change without needing to use SharpKeys


As I said before I have done this successfully several years ago though so far I haven't found the database where I did it.

Normally I don't allow end users to run mission critical procedures.
My approach is to restrict these to program admins or to run these as a scheduled task outside of work hours
Would that work for you?

Interestingly I've had the opposite problem of needing to find ways of interrupting a long procedure (approx 35 minutes) in an emergency where repeatedly pressing Esc or Ctrl+Break were having no effect

 

[Stormin]

Thanks for your continued support ridders.

I thought any key presses would only affect the program they were used in.

Me too! I was perplexed when I discovered this, and it is the biggest reason I want to be able to disable the ESC key's ability to cancel queries. I want to be able to carry on working while the update is taking place without worrying about keypresses.
Unfortunately I can still replicate this behaviour:
- Run import code in Access
- Open new Excel window and blank workbook
- Continuously perform actions such as Copy, then cancel with ESC; write in cell, then cancel with ESC; right-click for context menu, then cancel with ESC
- Once Access import code has run through (having never activated the window), there are cancelled queries

I am running Microsoft Office Professional Plus version 2016 MSO (16.0.4498.1000) 32-bit, on Windows 7 Enterprise SP1 64-bit, with an Intel i5-4210U dual-core processor.

I altered the registry to disable the Esc key completely

I think for company computers I would have an aversion to this method since if something goes wrong with the registry I'll have IT on my back. I'd prefer to limit Access to it's little VB settings registry section...

My approach is to restrict these to program admins or to run these as a scheduled task outside of work hours
Would that work for you?

How would I set this up as a scheduled task? Could you point me in the right direction for further reading? Both databases are in the same location in an always-on shared network location, but are not split into front-end and back-end (maybe an upgrade for the future).

 

[isladogs]

Well that's disappointing about ESC in Excel ...
I tried again but it still had no effect on Access on my PC
Anyway if it fails for you that's another approach to abandon

Disabling Esc in the registry affects all programs so I'm not surprised you didn't want that.

Not sure what you mean by

I'd prefer to limit Access to it's little VB settings registry section...

As you already know, Esc is not one of the 'special keys' as far as Access is concerned

How would I set this up as a scheduled task? Could you point me in the right direction for further reading? Both databases are in the same location in an always-on shared network location, but are not split into front-end and back-end (maybe an upgrade for the future).

I've used task scheduler (TS) successfully for many years though not in the recent past so I'm a bit rusty.
Prior to Windows 7, these used to be simple to use.
Nowadays, they are far more powerful but setting them up can take a little getting used to.

See attached for some info I issued to a client a few years ago as it covers most of the steps you need.
Its for a specific app called SDALink but the ideas are transferable.

Several important points:
1. Actions tab:
The Access program path goes in the Program / script box
The database path is entered in the arguments textbox (together with any command line arguments - - see below)
2. General tab - use Run whether user logged in or not
3. Conditions tab - use Wake computer to run this task
4. Settings tab - use Run task as soon as possible after scheduled task is missed

Test the scheduled task works when run manually
Then set to a time when you can watch it run automatically - note that if the PC is busy, it may run a few minutes late.
If any of this is unclear, feel free to ask questions

I mentioned command line arguments.
The SDALink app referred to in the attached info can be opened manually or using task scheduler in 3 ways:
a) normally (no command line arguments)
b) 'ExportOnly' argument
c) 'AttMarks' argument

As an example, the shortcut used for the last of these is:

C:\Programs\MendipDataSystems\SDALink\SDALink.accdb [B]/cmd "AttMarks"[/B]

That string works both as a desktop shortcut & used in the arguments textbox in TS.

In the SDALink app itself I have code like this in the Form_Load event of the startup form - there lots more unrelated code in there:

Private Sub Form_Load()

On Error GoTo Err_Handler

         Dim ComLineArgs As String

         'some code here not related to scheduled task ...  
   
            ComLineArgs = Trim(Command())
            ' /cmd dbName;reportName;printerName
            'MsgBox ComLineArgs
            'Debug.Assert "Break"
            
            If ComLineArgs = "ExportOnly" Then
                '21/09/2010 - Section added to allow export of spreadsheets earlier in the evening.          
                LogEntry "\  - Opened with arguments: " & ComLineArgs
                AutoFlag = True
                RefreshSpreadsheets 'run procedure
                LogEntry "/  - Opened with arguments: " & ComLineArgs
                If Not blnRunProcedure Then SendSystemEmail "Pre-Export failed"
                Application.Quit
            ElseIf ComLineArgs = "AttMarks" Then
		'12/05/2014 - Section added to allow import of attendance marks
                AttMarksFlag = True 'CR v543
                DoCmd.Close acForm, Me.Name 'CR v543
                AutoFlag = True
                RunAttendanceMarksUpdate 'run procedure
                Application.Quit
            Else 'no command line args - run normally - standard update
                DoCmd.Close acForm, Me.Name 'CR v527 - added to prevent endless loops in Auto mode!
                ...
                DoCmd.OpenForm "frmLogSession", , , , , acHidden 
                DoEvents
                DoCmd.OpenForm "frmMain"                
                ...                
            End If
	....
   
Exit_Handler:
    Exit Sub

Err_Handler:
    MsgBox "Error " & err.Number & " in frmStartUp Form_Load procedure: " & err.Description
    Resume Exit_Handler

End Sub

NOTE
I have NEVER tried to run a scheduled task over a network & expect it will be problematic if you try and do so
Suggest you set it up where the application(or FE) is located

If that pushes you into splitting the database, that's a good thing.
Personally I would treat that as a priority even if you're not in a multiuser environment but DEFINITELY so if you are

 

[The_Doc_Man]

In the research I did that I mentioned earlier, the behavior of "being in program XXXX and having <ESC> affect Access anyway" WAS reported. That non-locality of the scope of the <ESC> key was part of the concern of the posts I had found. As I previously stated, because of the incredibly wide scope of effect, the only interim workaround reported to be effective (for the persons complaining) was to use the registry to temporarily disable the key itself. Apparently, once <ESC> has been hit and fielded by Windows, it is too late for some other program to change it to something else. So if you have a KeyPress type of interception, it might work if Access is the active app and window, but the OP of that other article said that it interfered with other tasks if Access was in the background, i.e. not on top of the stack.

 

[isladogs]

In the research I did that I mentioned earlier, the behavior of "being in program XXXX and having <ESC> affect Access anyway" WAS reported. That non-locality of the scope of the <ESC> key was part of the concern of the posts I had found. As I previously stated, because of the incredibly wide scope of effect, the only interim workaround reported to be effective (for the persons complaining) was to use the registry to temporarily disable the key itself. Apparently, once <ESC> has been hit and fielded by Windows, it is too late for some other program to change it to something else. So if you have a KeyPress type of interception, it might work if Access is the active app and window, but the OP of that other article said that it interfered with other tasks if Access was in the background, i.e. not on top of the stack.

Doc,
It does now seem to be that way for the Esc key, yet you can block almost all single keys and some combinations e.g. Ctrl+C, Ctrl+V without editing the registry. By contrast, ctrl+Esc, ctrl+alt+del, alt+tab can only be blocked using the registry

And now i'm going to swop roles with you, as I know I could successfully block Esc in Access some years ago. Perhaps it was prior to accdb files (...if that's relevant)