Identifying whether Shift is pressed during opening a Runtime

[Gasman]

I am using the /runtime shortcut. Am I correct in assuming that Shift will not work in this case?

No idea. I have never used a runtime, merely an accdb/accde.
You can always try and see?

 

[isladogs]

As @Gasman said, its very easy to test this sort of question yourself.

Using an .ACCDR file is equivalent to using the /runtime switch
In both cases, the shift bypass was ignored

 

[theDBguy]

@JohnPapa

It is the second .accde which I want to be able to C&R.

...and if none of the users are using the BE DB I would like to enable the user to C&R the BE DB.

Pardon me, but the above two statements, taken from two separate posts (#12 & #14), seem to convey two different goals.

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?

In any case, I think you're having a hard time because you selected a trigger that means something special to Access itself, but you want it to mean something else in your app. Would you be able to achieve your goal if for example you tell the user to press the Ctrl key instead of the Shift key?

Just curious...

 

[Isaac]

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

Agree with @The_Doc_Man and @Pat Hartman
and would just add that in a true split db properly designed, my front ends are usually quite tiny in size - so tiny, in fact, that my versioning/deployment/install/opening scheme involves copying the network version to the local machine every time it's opened, which solves like a dozen problems at once.

but turning or leaving on compact on close is the worst.

 

[JohnPapa]

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

Hi Pam, I decided to use something along the lines you mention. As I mentioned I have a .accde which is runs and does some preliminary work and if everything is OK it runs the main .accde. Any C and R would need to happen when the first .accde runs. The first .accde cannot have BE tables because this would make it specific to a speciic user, so it is not practical to have a table which stores the C and R history. I thought of having a simple .txt file in the same folder as the BE. This .txt file stores 3 things, the size of the BE at the last C and R, a percentage, say 15%, so that if the current BE is more that 15% of the size of the last C and R and a YES or NO as to whether to attempt C and R.

Each time we exit the second .accde we calculate whether a C and R is needed. Each time we enter the first .accde, if a C and R is needed and if no other users are using the BE, a C and R takes place, with the BE being copied locally and then copied back.

If the .txt file does not exist, then nothing happens.

 

[theDBguy]

if a C and R is needed and if no other users are using the BE, a C and R takes place, with the BE being copied locally and then copied back.

Just curious, would it be possible as the C&R is happening, another user might attempt to open their own copy of the first accde? If so, what happens with them?