Javier: Not sure if you saw my last email from Thursday... We discovered the problem, although we haven't pinpointed the exact culprit. When the program is run from within a 7.6 Windows form, of course the database is already connected. So when he wanted to run the same program from a scheduled task, we called a program that needed to connect to the database first, then run this other program. If it was me, I would just have it CONNECT the database, specify a couple settings and that's it. Instead he called a generic "dbconn.rmd" program that he had created long ago that connects the database and must do about 100 different SET commands. Somewhere there's a setting that hammered performance. Funny thing is, they are still running some DOS programs as we convert them all over, and the DOS main menu calls this "dbconn.rmd" program, so it has probably been slowing them down for years without knowing it! Hopefully we'll get some time to see if there's a particular SET command that killed them. I'm not sure whether that program set a SCRATCH drive, or whether the scratch was on the network (it is local temp directory in 7.6 windows)....
Karen > Karen: > I have an application that runs every nigh from the Windows Scheduler. The > code for the executable is: > > -- Code for Load_Fuel.dat > CONN PMSDB > EDIT USING fuel_auto_load > DISC > EXIT > RETURN > -- End of Code > > All the code is contained in the After Start EEP. There are lots of PAUSE 4 > commands that update the status meter for each iteration. The last few lines > of this code are: > > PAUSE FOR 1 USING 'UPDATING SCREEN' + > CAPTION 'PROCESS PROGRESS...' icon attention > LABEL done > CLOSEWINDOW > RETURN > > Which closes the Form and then the database is disconnected and exits the > application. It used to run as: > > C:\RBTI\RBG75\RBG75.EXE -r Load_Fuel.dat > > And now it runs as a compiled application. No noticeable difference in time > of execution between the batch file and running the application from the R> > prompt. Of course, there is the time up front to start R:Base from the batch > file or the compiled application, but once it is up, it runs very fast. > > Javier,
