I am new to VisualCron and am evaluating it as a possible tool to replace our current job sheduling nightmare of Windows Scheduled Tasks and SQL Agent jobs. However I am struggling to work out how to duplicate what we currently do in Scheduled Tasks. In scheduled tasks we simply put our command eg
F:\Scripts\HourlyJobs.CMD F:\Scripts SERVER01 > F:\Scripts\Log\HourlyJobs.log
into the Run field on the first screen and we're away.
In VisualCron I have created an Execute task, populated the execute Command field with
F:\Scripts\HourlyJobs.CMD
populated the Arguments field with
"F:\Scripts" SERVER01
but I can't see where to put the filename for the output. I tried creating a second task (Write File) that wrote the VisualCron variables Output and Output(stderr) for the first task to the file, but I got an empty file.
Any help greatly appreciated.

Hi Ian,

by default, VisualCron captures all standard output which means that you can't redirect it that way. Instead, we provide a more flexible way to work with output. All output, stderr and stdout are captured and can be accessed through Variables.

You are on the right track but perhaps you used the wrong Variable? Which Variable do you use in the File write Task?

Also, after running the first Task I would just verify that it has Output by double clicking on the output column of that Task.

---

I am using the following variables
{TASK(1d3fb7e4-a661-4de2-ba2e-d79a637c6522,StdOut)}
{TASK(1d3fb7e4-a661-4de2-ba2e-d79a637c6522,StdErr)}

which I am getting from Variables, VisualCron variables, Jobs, HourlyBackup, Tasks, HourlyBackup, Output and Output(stderr)

The job fails as the Result field says Incorrect function. However both Output and Output(stderr) say No Output. Even if it failed it should write guff out, even if it's just the usual command lines repeated that you get when you run a CMD file.

It seems to fail before anything has been written. Try adding an echo at the top of the script.

It all depends on what the script try to do but the most common reason why this happens is because of lack of permissions. VisualCron is executing from the service (when using background execution) as SYSTEM account. Probably you need to run it as local admin or if you try to access network drives you need to add a Credential for remote machine.

---

Thanks for your help with this Henrik. I'm making progress. The problem was that in my script I was calling powershell as powershell (as windows would know where to find it from the PATH variable) but it seems that I need to explicitly put in the full path. Same with ./ for running powershell scripts. The job is now working correctly, but not all of the output is coming out. Just a subset. Is there some buffer for stdout that can fill up or that I can configure?

Scratch earlier post. Found it in Output Settings.

Thanks, I was having a similar issue.

As far as the number of output characters, is there any risk involved with not setting a limit on the output?

I don't care about the output unless there is an error in which case the output is emailed to me. I had it set to 6000, but ended up setting no limit at all. Say there is something with an output of 200,000 lines, would that cause any issues with the email notification being generated?

Thanks

Currently, such information is stored in memory. We are about to make some adjustments to that. 200.000 lines is not really much to handle in memory but potentially the email will be slow to download and send on a slow connection.

---

Oh okay that works for me then. I'm not concerned about the speed of the email as it's local only 😎 - so good deal, thanks for the info. I will continue to not limit output.

One issue though is that currently output is sent to the Client - so that the VisualCron Client can view it. This will make the connection between Client and Server slower and might be the best reason for limiting output.

What we will do in the future is to send this output only on demand. But currently that will affect you as well.

---

Okay that makes sense, but the cool part is that there's a gigabit ethernet between client/server so it shouldn't be a huge problem.

I have a task that runs a stored procedure that has a lot of output. I don't really need to see it unless there's an issue, but say the issue is 200,000 characters in and the limit is set to 100,000 characters...the email that contains {TASK(Active,StdOut)} wouldn't include stuff past 100,000 right? If that's the case, then I wouldn't actually see where the issue was. So in my mind, a little slowness is a better trade-off than not having the opportunity to see where the stored procedure had a problem.

Correct.

I have a task that runs a stored procedure that has a lot of output. I don't really need to see it unless there's an issue, but say the issue is 200,000 characters in and the limit is set to 100,000 characters...the email that contains {TASK(Active,StdOut)} wouldn't include stuff past 100,000 right? .

---