Task Runs from Command Prompt but not Task Scheduler

We have a simple task that reads records from a Pervasive database using ODBC and writes them to a SQL database.  The task can be run from a command line but NOT from the task scheduler which throws all kinds of  ODBC connection errors (HandleError for every table).  Security, logins, etc. are all identical for the logged in user and the task.
branudaAsked:
Who is Participating?
 
branudaConnect With a Mentor Author Commented:
Thank you for all of your comments.  While helpful, the solution was something else entirely - apparently the task was being run on a different server and for whatever reason, this was not allowed.
0
 
Patrick BogersDatacenter platform engineer LindowsCommented:
What kind of job is it? batch? cmd or powershell?
0
 
QlemoBatchelor and DeveloperCommented:
Does the task use ODBC DSNs? If so, they might be defined for the user instead of the system.
0
The new generation of project management tools

With monday.com’s project management tool, you can see what everyone on your team is working in a single glance. Its intuitive dashboards are customizable, so you can create systems that work for you.

 
branudaAuthor Commented:
cmd
0
 
branudaAuthor Commented:
There was a user DSN.  Now there is a System one but same results either way.
0
 
QlemoBatchelor and DeveloperCommented:
Make sure you don't mess up with 32bit and 64bit ODBC drivers. Task Scheduler might want to use 64bit executables.
0
 
branudaAuthor Commented:
we must use the 32 bit version to connect to pervasive.
0
 
QlemoBatchelor and DeveloperCommented:
Than make sure you call 32bit tools inside of the cmd file, or call cmd.exe from the SysWoW64 folder (instead of system32) in your task, e.g. with
  %WinDir%\SysWoW64\cmd.exe /c c:\Scripts\KillTheDb.cmd
0
 
mirtheilCommented:
What are the exact ODBC errors being thrown?
0
 
branudaAuthor Commented:
For EVERY table (so I have just written [tablename] in this example):

Fri 12/20/2013 10:00:24 PM  (Error)  -
                                   at System.Data.Odbc.OdbcConnection.HandleError(OdbcHandle hrHandle, RetCode retcode)
   at System.Data.Odbc.OdbcConnectionHandle..ctor(OdbcConnection connection, OdbcConnectionString constr, OdbcEnvironmentHandle environmentHandle)
   at System.Data.Odbc.OdbcConnectionOpen..ctor(OdbcConnection outerConnection, OdbcConnectionString connectionOptions)
   at System.Data.Odbc.OdbcConnectionFactory.CreateConnection(DbConnectionOptions options, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
   at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup)
   at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection)
   at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
   at System.Data.Odbc.OdbcConnection.Open()
   at [tablename].CreateSchema(String tablename, Table table, Int32 connectionID)
0
 
mirtheilCommented:
Is there any exception listed in the error?  
Are you using ODBC to both read and write the data?  
Is the error occurring on the read or write portion?  
Did this work at one point and stop or has it never worked?
Does the error happen every time you run the scheduled task?
0
 
branudaAuthor Commented:
No exceptions.
Using ODBC to both read and write.
It looks like the error is on the read.
This did stop working but the customer claims that "nothing has changed".
This happens every time the task is run and NEVER when run from a command line.
0
 
mirtheilCommented:
At this point, I would suggest adding some debugging code to it.  Something is causing the HandleError and you need to figure out what it is.  Ideally, the debugging code would write to a log or event log and show the line(s) of code that cause or at least precede the error. It would also, hopefully, give you a better error with exception or error message that's being returned.
I've written apps (.NET and standard Win32) using the Pervasive ODBC driver (and Pervasive Managed Provider) that run as scheduled tasks without any problems so I know it's possible.
0
 
DaveCommented:
If its server 2008 or later make sure you click the box which says "run with highest privileges"
0
 
ste5anSenior DeveloperCommented:
Do you run the task under the default account or under this user account?
0
 
QlemoBatchelor and DeveloperCommented:
You can also try whether the ODBC Trace shows something (useful).
Call %WinDir%\system32\odbcad32 and %WinDir%\SysWoW64\odbcad32 (ODBC Administrator)d 32 bit), open tab Tracing, set a different log file for both, and start logging. After executing the task, stop tracing.
This will show
a) which driver is used
b) if there is some exchange at all
c) details about the failing call
0
 
branudaAuthor Commented:
Changing servers that ran the task fixed the issue.
0
All Courses

From novice to tech pro — start learning today.