Python script not working in Windows scheduler

[JonahWaterman]

I have created a model to delete a database and then copy the sde feature classes to a file geodatabse and it works sucessfully in modelbuilder when I try and schedule it as a task in Windows scheduler its running but not giving me my results, I keep getting a (0X1) expression under theLastsuccessfully tab. THX FOR YOUR HELP

[Anonymous User]

OK, so you're executing a Python script...

First of all, have you tried cheking  the.. "...highest privileges" check box?

As you are running a Python script I think you should introduce in this text box ("Program/script") the Python.exe executable (if you're using ArcGIS 10.1, per example, C:\Python27\ArcGIS10.1\python.exe ). In the "Add argument" I should include the complete location of the Python script and its parameters (it the script has parameters).

Once this is done, I should try to use any way for logging the script execution:

You can add in the script:

import logging, os

# this two lines will create a log file in the same location the script file is

logpath = os.path.dirname(__file__)

logging.basicConfig(filename= logpath +'\\' +'logfile.log',level=logging.DEBUG,format='%(asctime)s %(message)s', datefmt='%m/%d/%Y %I:%M:%S %p')

# you can add this line to your script  each time you want to log that the script reaches that line:

logging.info("The script was here")

# remenber that you must mantain python indentation or tabulation.

And finally, a more complex (but better ) way, you can add a try/except block and capture the error and log it into this log file.. so you can see what is happening inside the script during its execution.

Hope this helps

Jesús

[TedCronin]

To follow up with what Jesus is saying, at the next release of Desktop you will have python 2.7 and python 3.4 installed, so you will need to point some scripts to 2.7 and some to 3.4 especially as some are ready to move forward and some are not, so with that said, you will reference the executable directly in the Program, and the actual path to the script in the Add Argument.  So for instance if you want to do an analysis script you could reference the python 3.4 exe, with a Argument of "the path to script", while some scripts may need to do topology checks, and those will need to still be able to just run under python 2.7, with the argument of "path to script".  Its probably best to practice now, since this is the way it will become in the future with the release of Pro.

Does this make sense?

[AnastasiaAourik]

I have many python scripts running in windows scheduler.  I do it by having a XXX.BAT or xxx.CMD

that I call in the windows scheduler.

the .bat or the .cmd has entry

python mypython.py

This works well for me.

[JonahWaterman]

Yeah I have created 5 new tasks in windows scheduler today and they all work except the database transfer script. I'll get back to the drawing board and retest tomorrow morning. Thanks for all the input today everyone.

[BryanMc]

We've had the issue where part of the script is blocked by the virus scanner when running via scheduler, and another issue related to using command line code in a python script - both have similar symptoms. You might need to add some logging to a text file to see if this is the issue when run from a schedule (as mentioned by Jesús Manuel de Diego Alarcón ).

[PaulHuffman]

You have that radio button for "Run only when user is logged on" clicked.  Is your account still logged on when the script is scheduled?

[AnnePayne]

Just a thought -

Make sure that you define the full external file path within your script.  Something like this:

net use L: \\gisdata1\gisdata batch password /USER:WAKE\gisbatch /persistent:no

GISBATCH/batch password is a user/pass that we have set up specifically for batch jobs with a password that doesn't expire.

This mounts your external drive - Batch jobs are dumb - they don't recognize drives mounted in your logon script, for example.