Unless you are prepared to do some complex gyrations, the answer is NO.
If you are executing code from a DB then that DB is open for reading by an active user (namely you) in the Access session. There will be a file lock associated with having a file still open. Most methods of deleting a file will try to take out an EXCLUSIVE WRITE lock on the file first before that method then issues the delete. But if there is a prior activity lock, even if only a SHARED READ lock, the attempt to establish the exclusive lock will fail due to a lock collision, and thus the deleting process will never GET to the point where the file system rules would allow the deletion. You would get an error "FILE LOCKED" and stop right there.
If this is a single-user file and ownership isn't a problem, you MIGHT be able to find the lock and downgrade it from SHARED READ to SHARED INTEREST (which is the least restrictive but non-zero lock). I wouldn't bet on that, but it MIGHT be possible. You could delete the file if the collision was over an INTEREST lock rather than a READ lock. However, lock interactions are complex on a good day and hellish when you are trying to side-step Windows file security. There are lock management API calls you could make to do the downgrade. Note that the file system might note that code is still executing from the file (assuming self-deletion) once you return from the API call and simply reassert the lock.
Arnel's solution doesn't work because your attempt to close the DB would fail if you are still executing code from a module in "y". You CAN open another DB (call it "z"), even in another instance, and you CAN run code from that DB - but at the code execution level, it is a
subroutine call that leaves the caller's ("y") info still on the process stack and that leaves the READ lock still active. Mechanically speaking, there is a "reference count" property on a file handle and that count would not be zero, so the attempt to delete would fail on the non-zero counter. (Have you ever tried to delete an Access lock file when someone still had it open?)
In theory if you tried this two-instance approach, the critical moment would be when you exited the subroutine from "z" only to find that there was now a problem with a lower level stack reference to "y" that would lead to a BANG-ZOOM moment as your process aborted on some insane stack violation. Because regardless of the number of instances that are open, there is still only one process and still only one process stack involved. What counts is what is in memory, not in any of the files.
Regarding the afore-mentioned "complex gyrations: Using an API-based function, it is possible to mark a file to move to the wastebasket at next reboot.
How would I go about marking one folder for deletion when the system reboots, using C#. Thanks,
stackoverflow.com
However, there are restrictions and the file system can be "picky." Since you are talking about an app file rather than a folder, some of the file system restrictions don't apply, but if you were trying to delete a folder, it would have to be emptied first. You aren't, so this is an easier case. If you did this, your file would still run but would now be marked for deletion at the next reboot.