Windows Scheduler and VB6 programs... cant run same app at same time using the scheduler


I have a program written in VB6. The program accepts a parameter, and if it is called with a parameter it runs without a form.  If there is no parameter it loads up a form.

If I call the program with parameter 3, it will pull a list of employees, it will take the first employee and run a specific stored procedure, create an excel file and then email that employee the excel file.  It will cycle through all employees until its done and then exit.

If I call it with parameter 19, it could pull a different list of employees, take the first employee, call a different stored procedure, create an excel file and then email that employee the excel file and continue on to the next employee.

This program works just fine when I run it manually (opens up a form and I choose the report, etc).
It works fine when it is scheduled and I pass a parameter to it.
It does NOT work fine when the scheduler call it and then, while its already running, the scheduler calls it again.

Lets say that each report normally takes 10 minutes to run.
I have the scheduler setup to run Program with Parm#3 at 10am and then run Program with parm#19 at 10:30.
If the 10am process is still running at 10:30 (when Program with parm19 is called) they are both hosed and will remain in the Running state until I cancel them.

Is there a way to get around this, so that the scheduler can call the same VB6 application whenever its needed without messing anything up?
Is this problem caused because its VB6?  Could I re-write this in .Net and we would not have this issue?
Is there some type of "wrapper" program I could call which could call the VB6 app in its own process/thread so that they don't get all hosed up?  Could I run this on Windows Server 2008 and bypass all of these hassles?
I am looking for the quickest method that would work.  It doesn't have to be pretty, it just needs to work.

Like I said, the thing works just fine until the scheduled become overlapped and then they both fail.

The server is Windows Server 2003, 64bit, SP2
I am hitting SQL Server 2005
   I use ADODB to call the stored procedure to get the recordset

I have Office 2010 installed on it, which is how I create the excel files, using code like:
    Dim xl  As New Excel.Application
    Dim xlwbook  As Excel.Workbook
    Dim xlsheet  As Excel.Worksheet

Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Have you checked the credentials for the scheduled task?  Can you set them to your own to test this?

Is the system it is running on already logged  in and at a desktop?  Or is it running on a logged off server?
 Try setting the event to run while logged into the desktop to see if it executes.  Also try it this way without any parameter and you'd expect out to start up in interactive more, right?

Lets start with that and I'll be able to check another idea in a bit

tfsaccountAuthor Commented:
We have an active directory account setup specifically for these reports and this account never expires, the user is setup as an administrator on the box. This user is used for all of the reports in the Run As user.

All of the reports are run while no user is logged on the machine... in fact, this server is a virtual server setup specifically for these reports, so unless I log in to make some type of change no user is ever logged into this machine.

I have logged in as the reports user to run the program and everything runs fine.
I have logged in as myself and everything runs fine.

If I manually run the report (either as myself or the reports user) everything runs fine.

It only fails when the scheduler runs and, while the application is currently running, the scheduler calls it again... at that point they are both hung.

When i first started to schedule things, I just assumed I could run as many instances as needed, and if they overlapped it should be fine.  When I had two schedules at the exact same time, the one error that appeared was: Error: -2147217871: [Microsoft][ODBC SQL Server Driver]Timeout expired
I have the code writing to a log file, which is where I got this error.  

So then I tried to stagger them, but occasionally something would happen that could cause different schedules to overlap.  When this happened I did not capture any error messages, it would just hang with both schedules in the Running state.

How does your application startup?  Is a form defined as the startup, and then just does not show when your parameters indicate it should run in an automated fashion?
10 Tips to Protect Your Business from Ransomware

Did you know that ransomware is the most widespread, destructive malware in the world today? It accounts for 39% of all security breaches, with ransomware gangsters projected to make $11.5B in profits from online extortion by 2019.

Also, how are you creating the Task Scheduler event?  Have you tried setting it up like the solution used here?
tfsaccountAuthor Commented:
I checked the link you provided, but that was for Windows Server 2008 and is different than Windows Server 2003. Apparently Server 2008 has some place to enter the arguments, whereas server 2003 doesn't have any special place for that.
The way I set it up is that I entered the full path in Run box, and I included the parameter here, such as c:\directory\reports\vbapp.exe 8 where 8 would be the parameter I am passing to it.
I put the directory in the Start In, such as  c:\directory\reports
Since there is no location for arguments, I didnt do anything there.

The form is defined as the startup.
If no parameters are passed to it, it loads some GUI information (what reports are available, etc).
If there are parameters passed to it, then go ahead and call the appropriate subs/functions to do what needs to be done.  Once it is done everything, loop through all forms and then unload form and then set form = nothing.  (for each F in forms, if not f is me then unload f and set f= nothing, finally do an unload me)

1. It isn't clear from your problem description whether the exclusion is a result of a started task decision or an application resource lock.

2. If you need to get data into an Excel workbook quickly, consider the method I describe in this article:

3. Can you queue your functional requests?  Rather than a scheduled task starting the current application, it starts a much smaller application that adds some request data to a file/database/folder.  It then checks if the program is currently running.  If not, then it shells the application.  You would need to change the application to look for requests in addition to the command line request.

4. Change the started task to start a new process to fulfill the request.  This would be the work-around if the scheduled task was not started because the prior scheduled task hadn't finished.  If the scheduled task is an app launcher, then it only lives for the time it takes to launch, not complete the application.

5. You might need to look at your workflow to better accommodate the request-fulfillment lengths.  For instance, if you know that a 3 is always followed by a 19, then you might start extracting/preparing the 19 data so it would reduce the time required for the 19 request fulfillment.  If you are doing things in a serial fashion, you might benefit from some parallel processing.
...And the big guns start showing up.  Aikimark always has some good ideas, so take heed.

As far as the current VB6 app, I'm wondering if the problem may be that the VB6 app starts with a form, even though it hasn't actually started displaying the form (if it were in interactive mode).  I'm guessing it's getting stuck on the Load event since it is essentially running as a scheduled task on a system not currently logged in.  This could match your observation.  I'm creating a test app now.
I just did a test and created 2 VB6 apps - one that starts with a form and one that starts with Sub Main(), but both immediately end as well.  I scheduled both as a task on a Win2003 server.  The one with Sub Main() started and ended correctly, the one with a form as the startup did not.  

So, tfsaccount, I'd suggest taking the code that is the Form_Load event, converting that into a Sub Main() in a module and set Sub Main() to be the startup for the app instead of the form.  Only call the form if it id dupposed to run in interactive mode.  Otherwise, no form interface should even be attempted to be displayed (and closed) at all.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
tfsaccountAuthor Commented:
Thanks for the suggestions, I will try them out in the next day or so to see if this solves the issue.
stay tuned :)
Also, look at the start-up code to see if it is referencing App.Previnstance
I think the core problem is that the app has a form as the startup  instead of a sub main() and is running under the SYSTEM user as a scheduled task.  So the change I proposed (36907773) should resolve it.  However, akimark's suggestions are also good, especially the suggestion to queue requests (36907550), I do exactly that on one of my programs.

if someone was looking did a suggestion, I'd split the points.
Martin LissOlder than dirtCommented:
This question has been classified as abandoned and is closed as part of the Cleanup Program. See the recommendation for more details.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.