How would one Break out of one's own run time programme? (1 Viewer)

[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.