Scheduled Script Failing Without Explanation

[Slug]

Yesterday I had a some scripts start failing that had been working for a couple of months without issue.

My setup is this. I have BC4 installed on Windows Server 2008 R2 Standard. I use SQL Server Agent to export web data to some text files and then call BC4 to send them up to our web servers. The SQL Server agent is logged in with and executes commands as [domain]\sqlagent. This is the only feedback I get:

Message
Executed as user: [domain]\sqlagent. The step did not generate any output. Process Exit Code 1. The step failed.

The operating system command being executed is:

"C:\Program Files (x86)\Beyond Compare 4\bcomp.exe" @"C:\webSiteDataExports\scripts\script.txt"

I've checked the following:

• BCProfiles.xml and BCSessions.xml have been copied in to C:\Users\sqlagent\AppData\Roaming\Scooter Software\Beyond Compare 4. I copied them after accepting the remote host's ssh key.
• The sqlagent user has all the rights it needs to read and write to the relevant folders.
• Windows Event logs... nothing gets recorded there.
• The log specified in the script. It doesn't get updated when calling the script from SQL Server. It's almost like the app is bombing before even reading the script.
• I can run the command while logged in to remote desktop on the server as [domain]\sqlagent and it works just fine.
• I've reinstalled BC4.

I've compared Process Monitor output from successes and failures and although I don't completely understand what I'm looking at I suspect it has something to do with 64 vs 32 bit. Is it a problem to be calling a 32-bit application (BC4) from a 64-bit application (Sql Server Agent)? Is there anything else I should look at? Any ideas???

[Aaron]

Hello,

The message that we "did not generate any output. Process Exit Code 1" is not generated from Beyond Compare. Exit Code 1 is returned from Beyond Compare for "binary same" when using the /qc parameter. When calling from script, it should be 0 on success, or 100+ for different script errors (see Help file -> Command Line Reference for a full list). Are there any scripts or steps in between the execution and the system command that could be crashing and returning a "1" value?

You mention this has worked for a few months. Did you apply an update to BC4 recently that broke the behavior? Or are there any other changes on your system? If you replace the command line call to BComp.exe with another program (like a call to Notepad.exe "c:\script.txt", or a simple test.bat with an echo command) does it generate the same error message?

[Slug]

Hi Aaron,

Thank you for responding. I'm not sure what's happening with the 1 because I'm not using the /qc parameter anywhere. Here's the entire script:

log normal "C:\webSiteDataExports\logs\script.log"
criteria timestamp size
load "webData"
sync update:lt->rt

There is nothing in between. Here's the step in the SQL Server Agent Job:



I haven't made any updates to BC4 or updates to the server. The only things I can recall doing in the last week was make some changes to Active Directory users and some Integration Services (SSIS) Packages.

I can call the script in a batch file logged in as SQL Agent and return an error level of 0:

C:\Users\sqlagent\Desktop>"C:\Program Files (x86)\Beyond Compare 4\bcomp.exe" @"
C:\webSiteDataExports\scripts\script.txt"

C:\Users\sqlagent\Desktop>echo 0
0

C:\Users\sqlagent\Desktop>pause
Press any key to continue . . .

The 0 after the echo is a %ERRORLEVEL%.

Maybe the computer just needs a restart. Even if it's Windows Server it is still Windows after all. I think I'll find a time today and kick everyone out and restart it.

-Mike

[Aaron]

A reboot is always a good troubleshooting step.

As for the bat file, does your SQL agent successfully work if you call a simple .bat (without any reference to BC4)? As in, replace your current call to bcomp.exe with test.bat and have the .bat file perform a simple task to see if this error is caused by the automation or the automation of BC.

[Slug]

Well, I posted my previous response at 8:33 and at 8:35 things started working again.

While I was testing I changed the owner of the scripts/files folder and that must have done it. Doesn't make sense to me since I verified a hundred times that my sqlagent user had "Full Control" rights to everything it touches and I hadn't modified the rights on those folders for quite some time.

As long as it's working I guess I can live with the mystery.

Thank you for your help!

-Mike