Identifying whether Shift is pressed during opening a Runtime

[JohnPapa]

I need to run a specific code on some occasions. I thought if I could identify whether the Shift key is pressed when the .accde is run, that would solve the problem.

Can we identify whether Shift is pressed during opening a Runtime

 

[Gasman]

ChatGPT states

You can't directly detect Shift key usage during startup, but you can infer it by checking if startup actions like the AutoExec macro ran. Use TempVars, global variables, or custom logs to help with this.

 

[JohnPapa]

Thanks for your reply. I do not understand ChatGPT's position.

 

[Gasman]

If you ask it, it will explain it's reasoning.
Basically you set a TempVar in an AutoExec. If that Tempvar is not set, then the Shift was used to open the DB.

Bit of lateral thinking.
You can prevent the bypass, you know that do you not?

 

[JohnPapa]

If you ask it, it will explain it's reasoning.
Basically you set a TempVar in an AutoExec. If that Tempvar is not set, then the Shift was used to open the DB.

Bit of lateral thinking.
You can prevent the bypass, you know that do you not?

Thanks. Yes, I use the ByPass. I do not use macros at all.

With the ByPass I merely set it to True or False.

 

[Gasman]

Well you will need to use the AutoExcec if you want to do what you want to do.

 

[JohnPapa]

With the ByPass the following is set to True or False

db.Properties!AllowBypassKey

Can't see how this can be used.

 

[JohnPapa]

Well you will need to use the AutoExcec if you want to do what you want to do.

Maybe I can do an exception and use the AutoExec, since the specific .accde is not the main program, but a ".accde", which calls the main .accde.

If I set a global variable to a value in AutoExec then that means that the Shift was NOT pressed, when I called the .accde?

 

[JohnPapa]

I tried it and it works fine. I added a simple msgbox statement.

The real reason for the Shift functionality is to be able to select when to Compact and Repair.

 

[The_Doc_Man]

You should be very careful about performing a C&R programmatically. There is a technical difference between automatic and manual C&R. When done automatically, code is running. When done manually, it is more likely that code is NOT running. The action of a C&R is summarized thus:

1. Make an empty database.
2. Step through the collections inherent in ANY DB and copy them, one collection at a time, including all content but not copying deleted items.
2.a - For tables, this includes copying the records, field definitions, and indexes (This is the bigger part of "Compact")
2.b - For all items, only valid non-deleted structures are copied. (This is the other part of "Compact" and the main part of "Repair")
3. Rename the initial DB.
4. Rename the new DB.
5. Delete the initial DB.

The problem is that in step 5, you are deleting the module in which your code was running. This is like the kids' cartoon image of sitting on a tree branch while sawing it off. Therefore, if you actually issued a command to do a compact & repair, the code running that command is about to go away. There is also a setting to do a C&R when closing the DB.

We have gotten reports that if a C&R fails, the result CAN become unusable. For this reason, we often suggest that a C&R should be done manually AFTER making a backup copy of the DB. (So that if it goes BANG ZOOM then you have an intact copy.) For various reasons, you don't want to make a copy of your DB via code because again you would be copying running code.

This next is MY opinion, perhaps shared by others... perhaps not. A front-end file should NEVER be C&R'd by an end user's action OR by automation, even if done implicitly. Instead, you should look into Pat Hartman's articles on auto-downloading a fresh COPY of the FE file each time you launch it. The developer can safely do a C&R on the master copy of the FE, so when you copy it, it IS as compact and as well repaired as it is going to get. Doing the FE download is about as fast as doing a C&R, but FAR safer.

Then set up a regular maintenance schedule that says "Every Wednesday afternoon at 3 PM" (or pick your other favorite time) "we will take the DB down for maintenance and backup operations." MANUALLY copy the back-end file or files to a temporary location, then C&R the BE manually, then make a "real backup" of the BE file that you will keep in an archive location. Then and only then, delete the backups from the temp area.

 

[Pat Hartman]

@JohnPapa In a production environment, the FE should NEVER need C&R, especially for an .accde. Unless of course you are using make tables or delete/add queries to empty/fill temporary tables. A better solution is to use a side-BE to hold the temp tables. Then your code can replace the side-BE every time your process needs to empty/fill the temp tables again.

Doc explained how I keep my FE's fresh because even without the make table and replace data problems, the database does bloat somewhat over time.

If you are talking about the BE, that should be a scheduled task that is run off hours when no one is logged in.

And finally, if the db is large, it isn't wise to do the C&R while the db is on the server. It takes a very long time because Access is running on the local PC and the db itself is on the server so Access has to copy everything from the server to the local PC and eventually put it back. This is very slow for reasons I don't understand and therefore is subject to the network "blips" that are not uncommon on LANs. The best procedure is to rename the BE on the server to prevent anyone from using it while the C&R is taking place. Copy the BE to the local PC, run the C&R, copy the be back to the server and archive the renamed version if you want.

 

[JohnPapa]

Many thanks for all your feedback. Let me explain better.

I have two .accde files. The first .accde checks things such as bitness, whether there is a connection to the Internet, whether a BE exists.

If everything is OK the first .accde calls the second .accde, which is the main program. It is the second .accde which I want to be able to C&R. At the time of C&R the second .accde is not running.

With this setup I can even download a new version of .accde automatically, whether 32-bit or 64-bit. The process is transparent to the user and very quick since the .accde is zipped.

Pam is correct about the fact that C&R on a server is slow, so I always prompt the user for a local folder where the db is copied to from the server and then copied back. For a BE of about 250Mb it is fast.

Going back to my original question, I will try using the AutoExec macro, this being the first macro that I ever used for obvious reasons.

 

[Pat Hartman]

If you have a special purpose, do not use the Autoexec. Create a use specific macro and open the db with the /m yourmacroname option to run that macro.

The macro runs whatever code you want. Don't try to do what you want in the macro itself unless you're a glutton for punishment. Be sure to close the db as the last step of the macro.
steps:
1. run your code function
2. close the db

That's it for the macro.

 

[JohnPapa]

Hi Pam, as I mentioned the functionality which I would like to add in the first .accde is to check whether the BE DB is used by any of the users and if none of the users are using the BE DB I would like to enable the user to C&R the BE DB. If any of the users are using the BE Db then no C&R would be possible.

I want to be able to give this option by running the code in the first .accde, by having the user press on the Shift key when running the first .accde. Identifying the Shift pressing is the trigger.

 

[Pat Hartman]

It's Pat, John.

Somewhere on @isladogs website is a link to a database that shows the active users in a database. You can use the code within that module to examine the roster list. Don't worry about what your name appears as. All you care about is that the db has only a single active user.

As I said. I would not use this method. You should not rely on a user to remember to do a C&R.

However if you don't want to create a scheduled task, you can create a table in the BE that you use to log the last C&R that happened on demand. In this table once the C&R is complete, you can update the last entry with the current size of the db. Then every time the FE opens, It can obtain the current size of the BE and compare it to the size at the last C&R and if the size has increased by more than 10% or whatever you deem the correct percentage, you can tell the user to run the C&R procedure or you can force it. You can also use the last forced C&R date to force a C&R at least once per month/week or whatever.

 

[isladogs]

Its ancient code but ....

Logged In Users

This utility allows you to select any Access database and monitor who is currently using it

isladogs.co.uk

 

[JohnPapa]

It's Pat, John.

Somewhere on @isladogs website is a link to a database that shows the active users in a database. You can use the code within that module to examine the roster list. Don't worry about what your name appears as. All you care about is that the db has only a single active user.

As I said. I would not use this method. You should not rely on a user to remember to do a C&R.

However if you don't want to create a scheduled task, you can create a table in the BE that you use to log the last C&R that happened on demand. In this table once the C&R is complete, you can update the last entry with the current size of the db. Then every time the FE opens, It can obtain the current size of the BE and compare it to the size at the last C&R and if the size has increased by more than 10% or whatever you deem the correct percentage, you can tell the user to run the C&R procedure or you can force it. You can also use the last forced C&R date to force a C&R at least once per month/week or whatever.

Good thoughts. Many thanks.

 

[JohnPapa]

If you ask it, it will explain it's reasoning.
Basically you set a TempVar in an AutoExec. If that Tempvar is not set, then the Shift was used to open the DB.

Bit of lateral thinking.
You can prevent the bypass, you know that do you not?

Hi Gasman, I have a .accde which has one form, which is specified as the startup form.

I tried to use AutoExec to open another dummy form and theoretically if Shift is pressed this dummy form would not be opened and in this way the user would know if Shift was pressed. The dummy form is opened when Shift is not pressed and is not opened when Shift is pressed, BUT cannot check from the main form whether the dummy form is open or not. Any ideas?

 

[Josef P.]

You can use a Win API function to check whether the mouse button is being held down at the current time.

 

[Gasman]

Hi Gasman, I have a .accde which has one form, which is specified as the startup form.

I tried to use AutoExec to open another dummy form and theoretically if Shift is pressed this dummy form would not be opened and in this way the user would know if Shift was pressed. The dummy form is opened when Shift is not pressed and is not opened when Shift is pressed, BUT cannot check from the main form whether the dummy form is open or not. Any ideas?

No need for the AutoExec to open a form I would have thought?
It is just there to see if shift was pressed on opening the DB.
So if not used, either do nothing or open your startup form, and take it out of the DB properties.