February 25, 2003 at 2:21 pm
Another frustrating stumper...
We have scheduled tasks in SQL Server, a couple of which run FoxPro executables. They quit running yesterday, and I need to figure out why.
The symptoms are, as usual, maddening. In Enterprise Manager, under 'Management -> Jobs', it always says everything worked fine. However, it returns in one second and the data do not get moved... exactly as if the job just blows you off.
I noticed then that, logged into Query Analyzer as 'sa' and using 'xp_cmdshell', I could not run any FoxPro executable. I can run BAT files and operating system commands, but attempts to run FoxPro executables just earn me dumb looks. Why would FoxPro just quit running for the SQL service owner?
In the grand tradition of DTS and other malware features of SQL Server's front-end stuff, there are no error messages.
When things like this happen, mostly the problem involved security context. However, since the owner of the database services is an all-powerful system admin login, that should not be a problem.
We can run the executables manually. But for some reason, SQL Server can no longer initiate them.
Any clues why? Information would be greatly appreciated.
February 26, 2003 at 7:27 am
Doesnt it have a run time? Maybe got deleted, unregistered, damaged?
Andy
February 26, 2003 at 7:41 am
quote:
Doesnt it have a run time? Maybe got deleted, unregistered, damaged?
In Enterprise Manager, the run times are showing up as zero or one second. I don't know what could be getting unregistered or damaged. I can run the executable on the server, just not through DTS, the Job Scheduler, or xp_cmdshell. When trying to run through the database, it acts like it cannot even detect the FoxPro executable.
February 26, 2003 at 10:23 am
Seems like it must be security, somehow? Have you verifed that the path to the exe you're trying to run is correct? What happens if you run a bat that calls the exe?
Andy
February 26, 2003 at 2:20 pm
Thanks for the suggestions, Andy. It turns out that we used the *.BAT idea, but it was inconclusive. I wound up questioning my assumptions. I had assumed that the FoxPro executable was not being called, because, not knowing FoxPro, I had taken the word of the programmer that the executable would stick a message in a file if it were executed. But now I considered, what if the executable is being called, but just isn't working?
I decided to browse the code. And sure enough -- I may not know FoxPro, but I know a conditional display when I see it! The FoxPro module would only execute the display if other conditions were met. So I asked, would the programmer please like to display something unconditionally, so I really can test whether the interface from SQL Server to FoxPro is really broke?
Not surprisingly, we found that the FoxPro executable was getting executed after all, but there was some sort of bug in the FoxPro environment preventing it from performing its designated function.
We eventually deduced that FoxPro now assumed the "current" folder was C:\WINNT\SYSTEM32, rather the folder in which the executable resided. Thus, FoxPro could not find his configuration file, and so did not do what he was told.
So we now know the "what", but not the "why". Something must have happened to cause the change in attitude (i.e., last week it worked, now it doesn't). For some reason, FoxPro's current folder started defaulting to a different folder. Dunno.
We fixed the problem by, in the scheduled job call line, specifying a -C parameter to tell FoxPro which folder to assume as the default. Never had to do that before.
February 26, 2003 at 3:40 pm
Interesting. I "think" the current folder can get changed by an app, or even someone using explorer. Probably good practice to either pass the path to the app or have the app know explicitly where to look. Hindsight!
Andy
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply