Major bug in all versions of Access: handling of ESCAPE key
n all versions of Access that I am aware of, going back at least to Access 2000, the escape key cancels queries (whether select, update, append, etc.), and recordset operations (running in VBA).
On the surface this may be fine, but there is a major bug in the implementation: Access "listens" for the escape key regardless of whether it has the focus or not.
So for example, if you have a long running append query and then open Excel, Word, Outlook, or even your browser (any software, presumably), and hit the Escape key to cancel an action in that other software, Access will "hear" it, and cancel your update query!
I've been able to reproduce this bug in Windows 7, 8.1, and 10, with Office 2013 and 2016. This has cost me and my clients hours of lost work. New clients now need to be taught to avoid hitting the escape button under any circumstances. It's a bug that needs fixing right away. This is unacceptable, and it's impossible to believe that Microsoft doesn't know this is going on.
Can we get this reported and given high priority?
Thanks you for posting and making us aware of this issue. We added it to our backlog and we’ll take a look at this and investigate.
It's been a year, Michal, can you tell me if there's been any further consideration of this issue? I've got clients working on multi-million dollar projects and losing one to two hours of work due to an errant keystroke is unacceptable.
If this were to happen at the worst time - right before a deadline - it could literally cost my clients millions of dollars.
Any update on this issue? It's become more urgent as my use of Access is becoming more advanced.
I've built a C# keystroke monitor and while it can note the escape key, and attempts to suppress it, Access still 'hears' the key press and still experiences failure.
Frank Rotolo commented
Some of my users will soon migrate from the Informix application I developed 25 years ago to Access 2010. In Informix, the escape key is used for committing transactions, and I can anticipate these users will accidentally press the escape key, so I really need a way to disable escape.
Thank you Michal.
Jason, I have observed and reproduced (just now) this error on both Execute and docmd.openquery calls. Also occurs when applying a filter programmatically (Me.FilterOn=true)
Jason Cox commented
Does this just effect one object model? That is does it only happen with DAO objects (database.execute) or does it happen with docmd.openquery too? What about the ADO object model?
Yep, same here. Happens even if the application window isn't active. Costly and annoying.
This has happened to me too. It's a serious problem.