I'm not sure if DoEvents is a good idea.
DoEvents' purpose is to relinquish control to the system to allow other
tasks in queue to processing. However when used as a ad hoc 'wait', it
actually can make things even more slower because it will be checking
and thus bothering the system when it tries to do something.
Four options comes to mind:
1) Use DoCmd.Hourglass to change the pointer to hourglass. You may
already have done that, but I included this for completeness.
2) Turn off Application.Echo which will suspend the screen drawing. The
input also will not be accepted during that, which is useful for a brief
period, but if it's turned off for too long, it may lead users to think
it's frozen and give the application the good ol' three fingered salute.
But if used in conjunction with #3 or maybe just StatusBarText so the
user know it's doing some background processing, it's good way to speed
up the processing.
3) Use a modal & popup dialog form to communicate to the user that a
task is processing. The input will also not be accepted and this
provides more feedback to the users.
4) Use a API call. There is a API for "Sleep", which I'm sure if you
google for "Sleep API Visual Basic", you can find the declaration and
use it to wait for X milliseconds.
That said, it should be unnecessary to need to sleep or wait with
properly written code, even for tasks that may be executed
asynchronously. For that reason, I usually would take a step back and
re-think about how it can be re-written in a way that it's either
handled already or is nonissue.
HTH.