How would one Break out of one's own run time programme? (4 Viewers)

[RaptorRaptur]

Hi All
Is it feasible to create a "break out" routine in a run time version of my software, activated by say, ctrl, F5 and a Q, to allow me, the developer, to crash out of the app into an Access mode in a split database that under normal circumstances would not allow the users to do so?
if yes, I would appreciate some guidance as to how to do it.
Thank you,
Alan

 

[theDBguy]

Did you disable the shift bypass?

 

[RonPaii]

If you are using runtime, then no, because runtime does not provide the Access user interface to break into.

 

[tvanstiphout]

How is this software being deployed?
1. as an ACCDB
2. as an ACCDE or ACCDR (renamed ACCDE)?

When running on the user's workstation, is it running on the full version of Access, or on the Access runtime?

 

[RaptorRaptur]

If you are using runtime, then no, because runtime does not provide the Access user interface to break into.

Even if MS Access is on the same machine??

Thanks Alan

How is this software being deployed?
1. as an ACCDB
2. as an ACCDE or ACCDR (renamed ACCDE)?

When running on the user's workstation, is it running on the full version of Access, or on the Access runtime?

I'm not sure, Currently both the fe and be are ..mdb files. I am just askling as an "in case" scenario once it is running on a client's machine, would I be able to get to the databases if I needed to?

Regards

Alan

Did you disable the shift bypass?

Hi there,
Yes I will. This is not an immediater need. It is in case I have to provide some support at a client's premises.
What I am really asking is "If a client is in trouble. What could I do? Keep a copy of the FE with me when visiting clients? Or a copy of my development "open application"?"

Regards,

Alan

 

[RonPaii]

Even if MS Access is on the same machine??

Thanks Alan

I'm not sure, Currently both the fe and be are ..mdb files. I am just askling as an "in case" scenario once it is running on a client's machine, would I be able to get to the databases if I needed to?

Regards

Alan

Hi there,
Yes I will. This is not an immediater need. It is in case I have to provide some support at a client's premises.
What I am really asking is "If a client is in trouble. What could I do? Keep a copy of the FE with me when visiting clients? Or a copy of my development "open application"?"

Regards,

Alan

If the client is on runtime, there isn't much you can do to get into the running application.

Adding external logging to a shared network drive is my 1st choice. I log all errors and some in-process problems. The log line starts with date/time then Computer ID, User ID, Windows version, Access version, Runtime or Full Access, FE version, Module and Function name, Error number, Error message, any extra message you want to pass. With the logging I was able to remove most message box warnings which only served to annoy the users. Now when I get a call about a FE problem, my 1st step is to check the log file. You will find far more bugs the from user reports. In fact if you start monitoring the logs you will find bugs the users never noticed.

Add a button to your FE to email the log to you or use remote access to your client's computer.

Debug your copy of the FE and supply an update to the client. Each change no matter how small is entered into the revision table with a new revision number.

 

[Cotswold]

I would have thought that Alt+Ctrl+Delete would be the only option.
But would you want to tell your client to use that? I always took the view that the less they knew the better and whatever they do you should be in control of anyway.

 

[The_Doc_Man]

Hi All
Is it feasible to create a "break out" routine in a run time version of my software, activated by say, ctrl, F5 and a Q, to allow me, the developer, to crash out of the app into an Access mode in a split database that under normal circumstances would not allow the users to do so?
if yes, I would appreciate some guidance as to how to do it.
Thank you,
Alan

Feasible, yes. Simple, maybe. The question is, does the keyboard still work when you get into the bad situation? If so, you can do this:

1. Hit CTRL/SHIFT/ESC - which is the shortcut to launch Windows Task Manager
2. Switch to the WTM window. Maximize it.
3. Select the Processes display. Inspect it to find the running Access process.
4. Select the line containing that process.
5. Right-click on that line, then immediately click "End Task" (usually 2nd item in the dropdown list of actions)

IF it happens that the app is intercepting ALL keystrokes, this approach might not work, though Dave Cutler (one of the designers of WinNT) says that some keystrokes of the "simultaneous press" variety bypass most key interceptors. Which is why CTRL/ALT/DEL - the infamous three-finger salute - will also work to stop even runaway programs. IF it is possible for WTM to respond, it will leave your client logged in but with that runaway program no longer running away. Unfortunately, if there was an update underway, it risks corrupting the DB, which is the same fate you would face with CTRL/ALT/DEL and my other favorite for getting a computer's attention - pulling the plug.

EDIT: Misread part of this because I was in a rush. What I posted is how you get out to Windows without logging out like CTRL/ALT/DEL would do. To get out of execution and break into Access GUI so that you can do some twiddling of the FE, as I understand it, if it is a "true" runtime environment, you cannot do that. If it is a fake runtime because you renamed the .ACCDE to an .ACCDR, there is still the problem that you can't see the code text in a DE because it ain't there. If you use a fake runtime of changing an ACCDB to an ACCDR, I think Access still wouldn't allow that, but you COULD have started a program with the "real" FE (or better still, a copy of it) and just launch it. The whole point of a runtime execution is that there IS no development mode. You put it into a runtime situation to PREVENT development mode.

In general, if you have a requirement to break out of code so you can twiddle, you have to design your solution up front before you implement anything.

This link points to a similar question to yours for which our member, Albert D. Kallal posts a lengthy discussion.

VBA Access Stop Command - Microsoft Q&A

Hi all Since I have installed O365 2016 when I use the command Stop to break execution Access close throw the message: Microsoft Access has stopped working like in this image Now with the 2008 Version the situation got worse because this…

learn.microsoft.com

 

[RonPaii]

I would have thought that Alt+Ctrl+Delete would be the only option.
But would you want to tell your client to use that? I always took the view that the less they knew the better and whatever they do you should be in control of anyway.

That would be a way to get to task manager and shut down Access but the OP was looking to get to the code to see what is happening.

 

[Cotswold]

That would be a way to get to task manager and shut down Access but the OP was looking to get to the code to see what is happening.

Maybe a few more error handlers in Functions & Subs to display the error on the screen as the user proceeds through the program. One easy way is to stick advancing numbers through the code that the error message can show along with the message. The developer can then look at that actual location and prevent it ocurring again.

There is little more annoying than software that states : "THERE WAS AN ERROR" - and fails to show the reason, or where it was found. After all to state that an error exists, the developer knows exactly what it is. So why not say? It is no trouble to do that.

 

[arnelgp]

i think that you would need to carry the db (accdb/mdb) with you.
you should have a copy at home and copy with you.
if there is need for some enhancement request, you work on the mdb, then later
convert it to runtime.

 

[RaptorRaptur]

i think that you would need to carry the db (accdb/mdb) with you.
you should have a copy at home and copy with you.
if there is need for some enhancement request, you work on the mdb, then later
convert it to runtime.

Good thinking but with my luck, I will be 40kms from home when I get the urgent call. Still, as a boss i used have always said "If the job was easy and fun, we would charge you admission, not pay you a salary!"

 

[RaptorRaptur]

Maybe a few more error handlers in Functions & Subs to display the error on the screen as the user proceeds through the program. One easy way is to stick advancing numbers through the code that the error message can show along with the message. The developer can then look at that actual location and prevent it ocurring again.

There is little more annoying than software that states : "THERE WAS AN ERROR" - and fails to show the reason, or where it was found. After all to state that an error exists, the developer knows exactly what it is. So why not say? It is no trouble to do that.

One easy way is to stick advancing numbers through the code that the error message can show along with the message.

That isd bloody brilliant. So simple that I was too dumb to see it. I will start doing it immediately. I would add one extra thing though. Rather than just a number something like "CR012" to make it easy to find it using access search facility.
Thank you,
Alan

 

[The_Doc_Man]

When providing the numbers, remember that error handling can sometimes be tricky. If you have Sub A that calls Sub B, which calls Function C, but function C doesn't contain error handling, it will be Sub B's error handler that intercepts the error. Therefore, you might wish to have a global "locator" string that you can include in the error message so that you can tell the difference between errors in Sub B and Function C. By that, I mean that Function C might not need to actually handler errors but you might wish for it to leave "footprints" that routines up the stack from it could report the recorded "milepost".

And it gets worse if Sub B doesn't have error handling either, because then Sub A handles everything in that call stack. There is a fine art to error handling. If all you want is a place marker and you know the program is going to crash, one Error handler per event is plenty. If you want information specific to the context of the error, you need many error handlers, one for each Sub or Function. There is also a middle ground, of course, in which you just KNOW that some routines CANNOT throw an error - because they are too simple to toss a complex error.

 

[Jason Lee Hayes]

Yes, it can be done, but it’s still outside the scope of this forum. You’d need a solid binary debugger — x64dbg is the one I rely on most — along with reverse‑engineering tools like Ghidra. Even with the right toolkit, without deep technical knowledge you’ll run into limits very quickly.

In practice, you’d set a hardware breakpoint on the target address .x64‑class CPUs provide four dedicated debug registers, and you load the address into one of them, so the CPU triggers an interrupt whenever that location is read, written, or executed hence a forced breakpoint. This method i use regularly for professional software reverse engineering therefore not only applies to Access but any application running in x32 or x64.
A little-known undocumented feature of windows is that link library's always load into the same address for every process!