I have an MS Access mdb that runs under Win2k Server. The job creates a text file on disk for each of multiple clients, then emails (SNTP) the text file to the client.

I wish to automate this using the 24x7 scheduler, but when I schedule the job, it launches it, goes through the motions(creates data tables, updates tabls, etc) but the only text file to actually get created and then emailed is the very last one in the process.

If I run the MS Access job from the desktop, all works well.

Any ideas?

Using 24x7 upgrade 3.4.11 (it is Licensed)

: I have an MS Access mdb that runs under Win2k Server. The job creates a text
: file on disk for each of multiple clients, then emails (SNTP) the text
: file to the client.

: I wish to automate this using the 24x7 scheduler, but when I schedule the
: job, it launches it, goes through the motions(creates data tables, updates
: tabls, etc) but the only text file to actually get created and then
: emailed is the very last one in the process.

: If I run the MS Access job from the desktop, all works well.

: Any ideas?

: Using 24x7 upgrade 3.4.11 (it is Licensed)

that was supposed to be SMTP not SNTP. The MS /Office Access version is Win2K Enterprise with all service packs etc.

How do you actually start your MS Access application?
Have you tried creating a batch file with the required command line and scheduling the batch?

: that was supposed to be SMTP not SNTP. The MS /Office Access version is Win2K
: Enterprise with all service packs etc.

I used the method in the MS Access Example under
Overnight Job Schedule, which is to say that I used
the Browse button to point to the command line
executable and the Start In browse button to point
to the target area. Job was set as asyncronous and
detached as well.

Are you suggesting that I create an MS-DOS batch file
with content similar to

c:\
cd c:\ProgDir
"c:\Program Files\Microsoft Office\msaccess.exe" "c:\ProgDir\ProgName.mdb"

??
Keep in mind that the program actually process its
data, it just won't create the multiple text files
and then email them out.

The mdb has an AUTOEXEC macro which has one line of
code: runcode "RunDailyJobs"

To answer your question I have not created and
scheduled a DOS batch file. I will do that now and
let you know the results.

Your question leads me to wonder if the Scheduler
is still subject to MS DOS and NT4 limitations???

Someone suggested that I write a VB Script to launch
the mdb in the hopes it would create a Windows
"container" arond the job. What are your thoughts on
this?

Thanks.

: How do you actually start your MS Access application?
: Have you tried creating a batch file with the required command line and
: scheduling the batch?

I am not aware of the mentioned "MS DOS and NT4 limitations"
I just know that when you open the MDB file manually the macro runs fine. But when the process is run in the background it somehow behaves differently.

That's why I suggest using a batch file as a container and see if it makes any difference. I am not sure if using VB or other container types make any difference. I just feel that the real issue is running the process in the background/foreground or using different user accounts or environment settings. Please note that when the MDB process is started from 24x7 it inherits all attributes of the parent process. When it is I run manually it inherits all attributes associated with the interactive user process.

The best troubleshooting path is to modify the macro and add some logging functions to the process so that if something goes wrong or simply cannot be found you could have a trace of it. Of course this can be done only if you have control over the MDB file and can modify it.

: I used the method in the MS Access Example under
: Overnight Job Schedule, which is to say that I used
: the Browse button to point to the command line
: executable and the Start In browse button to point
: to the target area. Job was set as asyncronous and
: detached as well.

: Are you suggesting that I create an MS-DOS batch file
: with content similar to

: c:\
: cd c:\ProgDir
: "c:\Program Files\Microsoft Office\msaccess.exe"
: "c:\ProgDir\ProgName.mdb"

: ??
: Keep in mind that the program actually process its
: data, it just won't create the multiple text files
: and then email them out.

: The mdb has an AUTOEXEC macro which has one line of
: code: runcode "RunDailyJobs"

: To answer your question I have not created and
: scheduled a DOS batch file. I will do that now and
: let you know the results.

: Your question leads me to wonder if the Scheduler
: is still subject to MS DOS and NT4 limitations???

: Someone suggested that I write a VB Script to launch
: the mdb in the hopes it would create a Windows
: "container" arond the job. What are your thoughts on
: this?

: Thanks.

Well I created an MS-DOS batch file with the command
line appropriate for MS Access and the application,
and ran it in both "Test" and "Normal" modes with
the "Run Now" button. Also ran it from DOS command line.
No difference.

It performed exactly the same as it had when I used
the browse buttons to point to the commandline and
the Start-In text boxes.

It is frustrating as I can see that it properly
processes the data but will write and email ONLY
the very last file created by the program.

I embedded a step logging process in the application
and can see that it performs all code as intended,
even to the point where it writes the file and then
emails it. No errors are raised at these points.
MS Access is convinced that it had a good day.

I have tested this appl using the Win2K task
scheduler, Guess what. It acts nearly identically
there also.

As the MS Access appl uses the Export command to
export a single previously formatted 80 byte wide
field out to a text file, then emails that text file,
I am thinking that perhaps the little informational
message box that MS Access displays when exporting,
may be the culprit.

I am going to try suppressing the display of that box.
Will let you know if that works or not.

: I am not aware of the mentioned "MS DOS and NT4 limitations"
: I just know that when you open the MDB file manually the macro runs fine. But
: when the process is run in the background it somehow behaves differently.

: That's why I suggest using a batch file as a container and see if it makes
: any difference. I am not sure if using VB or other container types make
: any difference. I just feel that the real issue is running the process in
: the background/foreground or using different user accounts or environment
: settings. Please note that when the MDB process is started from 24x7 it
: inherits all attributes of the parent process. When it is I run manually
: it inherits all attributes associated with the interactive user process.

: The best troubleshooting path is to modify the macro and add some logging
: functions to the process so that if something goes wrong or simply cannot
: be found you could have a trace of it. Of course this can be done only if
: you have control over the MDB file and can modify it.

Wait, you are sure that an access point of view it does all the setps, creates all files and sends all emails. Then where these files and emails go? Assuming that you use MAPI and Outlook to send emails can you check if having Outlook running all the time makes any difference? You also should see all these emails in the Outlook "Sent" folder.

: Well I created an MS-DOS batch file with the command
: line appropriate for MS Access and the application,
: and ran it in both "Test" and "Normal" modes with
: the "Run Now" button. Also ran it from DOS command line.
: No difference.

: It performed exactly the same as it had when I used
: the browse buttons to point to the commandline and
: the Start-In text boxes.

: It is frustrating as I can see that it properly
: processes the data but will write and email ONLY
: the very last file created by the program.

: I embedded a step logging process in the application
: and can see that it performs all code as intended,
: even to the point where it writes the file and then
: emails it. No errors are raised at these points.
: MS Access is convinced that it had a good day.

: I have tested this appl using the Win2K task
: scheduler, Guess what. It acts nearly identically
: there also.

: As the MS Access appl uses the Export command to
: export a single previously formatted 80 byte wide
: field out to a text file, then emails that text file,
: I am thinking that perhaps the little informational
: message box that MS Access displays when exporting,
: may be the culprit.

: I am going to try suppressing the display of that box.
: Will let you know if that works or not.