Access Automation
Ed Mana
1. I need to have the app open and print a specific report once each
day at a specific time.
2. I need to have the app take the same report, print as a .pdf, and
store it in a specific folder.
Both things need to happen even if Access is not open on the PC.
Any ideas?
TIA,
Ed
Steve Jorgensen
Access has a command line option called /cmd. This allows text on the Access
startup command line to be accessible from Access code via the Command()
function which returns a single string containing everything on the command
line following the /cmd option.
Using this, you can use the Windows schedulare to execute commands like...
"C:\Program Files\MS Office 2K\Office10\MSACCESS.EXE" /cmd PrintReport
Your Access program can have an AutoExec macro that executes a VB function
that reads the contents of Command(), finds "PrintReport" and knows that means
to open the report, then call DoEvents to wait for the report printing to be
finished (a not-well-known use of DoEvents), then execute DoCmd.Quit to exit
Access.
It's a good idea to make sure that the task is running as a user who will
actually be logged in to the machine that runs the task when it runs.
Otherwise, if Access has any kind of an error and opens a dialog box, you
won't see it, Access will not quit, and the next time the task tries to run,
it will not work.
In my experience, no matter how much you debugged before you tried to run it
through Windows scheduler, something will go wrong when you try to run it
through scheduler, and you'll need to be logged in with the same user account
to find out what happened.
Lauren Wilson
<nos...@nospam.nospam> wrote:
>On 28 Sep 2004 14:28:08 -0700, em...@technologyondemand.com (Ed Mana) wrote:
>
>>I have an Access app that I need to automate in 2 ways:
>>
>>1. I need to have the app open and print a specific report once each
>>day at a specific time.
>>
>>2. I need to have the app take the same report, print as a .pdf, and
>>store it in a specific folder.
>>
>>Both things need to happen even if Access is not open on the PC.
>>
>>Any ideas?
>>
>>TIA,
>>Ed
>
>Access has a command line option called /cmd. This allows text on the Access
>startup command line to be accessible from Access code via the Command()
>function which returns a single string containing everything on the command
>line following the /cmd option.
>
>Using this, you can use the Windows schedulare to execute commands like...
>
>"C:\Program Files\MS Office 2K\Office10\MSACCESS.EXE" /cmd PrintReport
>
>Your Access program can have an AutoExec macro that executes a VB function
>that reads the contents of Command(), finds "PrintReport" and knows that means
>to open the report, then call DoEvents to wait for the report printing to be
>finished (a not-well-known use of DoEvents), then execute DoCmd.Quit to exit
>Access.
This is very interesting. I have yet to fully understand the proper
use and purpose of "DoEvents". Would you be so kind as to explain
how, when, where and WHY a programmer might want to use it in an
Access app? Thanks very much for your contribution to this group.
>It's a good idea to make sure that the task is running as a user who will
>actually be logged in to the machine that runs the task when it runs.
>Otherwise, if Access has any kind of an error and opens a dialog box, you
>won't see it, Access will not quit, and the next time the task tries to run,
>it will not work.
Scary -- but strangely compelling! :-)
>In my experience, no matter how much you debugged before you tried to run it
>through Windows scheduler, something will go wrong when you try to run it
>through scheduler, and you'll need to be logged in with the same user account
>to find out what happened.
No doubt!
Steve Jorgensen
...
>>
>>Your Access program can have an AutoExec macro that executes a VB function
>>that reads the contents of Command(), finds "PrintReport" and knows that means
>>to open the report, then call DoEvents to wait for the report printing to be
>>finished (a not-well-known use of DoEvents), then execute DoCmd.Quit to exit
>>Access.
>
>This is very interesting. I have yet to fully understand the proper
>use and purpose of "DoEvents". Would you be so kind as to explain
>how, when, where and WHY a programmer might want to use it in an
>Access app? Thanks very much for your contribution to this group.
Well, the documented purpose of DoEvents is to allow Access to respond to
briefly allow Access to process other system events before resuming the code
that invoked it. For instance, let's say you have a long-running loop, and
you want the user to be able to cancel that loop.
One strategy that works id to put a toggle button on a form called Cancel, and
call DoEvents once each time through the loop. If the user has clicked on the
Cancel button, that action will be processes next time the code executes
DoEvents, and if the code then checks the state of the toggle button, it will
be True, indicating that the user clicked the button.
During a call to technical support several years back, I was told to use
DoEvents to solve a problem that I needed to print a report to a text file,
and have the code know when the report was done "printing" before trying to
manipulate the file. Without DoEvents, the next line of code executes before
the report has completed. With DoEvents, the entire report will be allowed to
complete before the code continues and executes the subsequent line.
Lauren Wilson
Thanks a LOT Steve!