Identifying whether Shift is pressed during opening a Runtime

[JohnPapa]

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.

Thanks Gasman. Can you please clarify:
1) Do I still define the Startup form?
2) What do I take out od DB properties?
3) How do I test if Shift was used?

 

[Gasman]

1. Up to you. If you open the form from the AutoExec, then No, otherwise Yes.
2. The startup form name.
3. The fact that AutoExec was processed or not?

So best to leave the form at startup alone and just create a simple Autoexec. The reason being, if you rely on the Autoexec opening the form and the Shift key is used to open the DB, you will not have that form open.

 

[JohnPapa]

1. Up to you. If you open the form from the AutoExec, then No, otherwise Yes.
2. The startup form name.
3. The fact that AutoExec was processed or not?

So best to leave the form at startup alone and just create a simple Autoexec. The reason being, if you rely on the Autoexec opening the form and the Shift key is used to open the DB, you will not have that form open.

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

 

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

 

[Pat Hartman]

Did you even try creating a macro for this specific purpose. As I mentioned, NONE of your actual code goes in the macro. All the macro does is to run your function and then close access. Who cares if the user used the shift key?

 

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

 

[Pat Hartman]

I'm not sure who you are talking to because as I mentioned earlier, my name is not Pam. All the experts have explained why you should not be running the C&R in production so do what you want. Apparently you know more than we do. If you use a log table it belongs in the BE, NOT the FE. If you are C&R the FE, then include a field to indicate for which user.

Your best bet is to fix the problem that is causing the bloat (I gave you suggestions on that also) rather than twisting yourself into knots trying to work around it.

You should NEVER need to C&R a FE in production. And C&R for the BE should be done on a scheduled basis and not left in the hands of users.