- Local time
- Today, 12:05
- Joined
- Feb 28, 2001
- Messages
- 26,999
The only way I know to abort a large file-copy via keyboard involves using a program intervention that would also break in on the app itself - which would certainly make it impossible for Access to manage the aftermath since at that point, it just got broken.
======
EDIT: But Colin knew of a way, so look at his stuff first. Still, there are many ways to approach this depending on how badly the file needs to be transferred, so you might wish to consider alternatives that let the user go on their merry way and not worry about the bloody file.
======
The stop-a-transfer problem comes about because Adam is technically correct even if his method of explaining is sometimes a bit off. Access is not capable of going multi-threaded. It is hard as all heck to make a parallel operation occur inside an Access app.
If you start a command to copy a file, whether via a File System Object or some other related method that stays within VBA, then you can try to hit the BREAK key. But it won't break until the copy operation is complete because that key doesn't interrupt the innards of Access. It can only break between lines of VBA code.
Your problem, as far as I can tell, is that your users get an itch to do something else and do extreme things to stop this copy operation. I am going to presume that you aren't allowed to shoot a few as examples (probably too much annoying paperwork), so let's try something else.
IF you have the ability to do a FileCopy or any other FSO operation to create files in a given destination, you might be able to create and then launch/spawn a separate batch job or an FTP Client batch job to upload to the server in parallel. In which case you would create the copy operation as a separate job. You would launch it and let it run merrily in background. Then your users wouldn't see that long delay. The only trick then would be if they are so stupid as to shut down their computer before they finish their job, then they shouldn't complain when being counseled about doing wrong.
Then there is the other issue - there is no reason they couldn't just open something else when the Access job is running. The only problem you would have at that point is if they start this putative long-running copy command and want to break away from that to use another part of the same Access app.
You COULD do something like write a separate Access app that can be launched in a way that it never becomes visible. Using a command-line argument, pass in the name of the file to be copied to this other machine and let it run. For examples, see this link:
https://support.office.com/en-us/article/command-function-fec67826-7fd7-48ed-a7aa-479c020ffaa4
which describes the Command function that returns at least part of the command line. You would launch this putative app using the Shell command.
https://www.myonlinetraininghub.com/vba-shell
Then when it is finished, you could have it pop up a message box that says "Your copy is complete." Then when they click OK, the box goes away and the secondary app does an Application.Quit for you so it goes away too.
======
EDIT: But Colin knew of a way, so look at his stuff first. Still, there are many ways to approach this depending on how badly the file needs to be transferred, so you might wish to consider alternatives that let the user go on their merry way and not worry about the bloody file.
======
The stop-a-transfer problem comes about because Adam is technically correct even if his method of explaining is sometimes a bit off. Access is not capable of going multi-threaded. It is hard as all heck to make a parallel operation occur inside an Access app.
If you start a command to copy a file, whether via a File System Object or some other related method that stays within VBA, then you can try to hit the BREAK key. But it won't break until the copy operation is complete because that key doesn't interrupt the innards of Access. It can only break between lines of VBA code.
Your problem, as far as I can tell, is that your users get an itch to do something else and do extreme things to stop this copy operation. I am going to presume that you aren't allowed to shoot a few as examples (probably too much annoying paperwork), so let's try something else.
IF you have the ability to do a FileCopy or any other FSO operation to create files in a given destination, you might be able to create and then launch/spawn a separate batch job or an FTP Client batch job to upload to the server in parallel. In which case you would create the copy operation as a separate job. You would launch it and let it run merrily in background. Then your users wouldn't see that long delay. The only trick then would be if they are so stupid as to shut down their computer before they finish their job, then they shouldn't complain when being counseled about doing wrong.
Then there is the other issue - there is no reason they couldn't just open something else when the Access job is running. The only problem you would have at that point is if they start this putative long-running copy command and want to break away from that to use another part of the same Access app.
You COULD do something like write a separate Access app that can be launched in a way that it never becomes visible. Using a command-line argument, pass in the name of the file to be copied to this other machine and let it run. For examples, see this link:
https://support.office.com/en-us/article/command-function-fec67826-7fd7-48ed-a7aa-479c020ffaa4
which describes the Command function that returns at least part of the command line. You would launch this putative app using the Shell command.
https://www.myonlinetraininghub.com/vba-shell
Then when it is finished, you could have it pop up a message box that says "Your copy is complete." Then when they click OK, the box goes away and the secondary app does an Application.Quit for you so it goes away too.
Last edited: