Changes (so far) in 6.1.1:

[BUGFIX] Client: Fixed a problem with scheduling across time zones
[BUGFIX] Client: Fixed Task order issue
[BUGFIX] Server: Fixed Web service Task Credential issues
[BUGFIX] Server: Fixed and issue with the Service Condition and remote computers
[BUGFIX] Server: Fixed Variable issue referring to a specific TaskProcess.Result
[BUGFIX] Client: Fixed "Get full output" issue (button disabled even though more output existed)
[BUGFIX] Server: Fixed an issue with loading referenced libraries in Unmanaged dll call Task

---

Hi Support

Have noticed in this version that if you Edit a Job, go into the Tasks, select a Task and click on the Change Task Order Spinner, the Task doesn't move up or down anymore.

cheers

andy

osirisja...you are right. They fixed the renumbering problem though :)
I hadn't used the up and down arrows next to the input box (spinners) before, interesting.
You can just type the number in of the slot you want it to go into.

Hi Trevinom

Yes - I found out if you just type the position number it jumps straight to it. Isn't really a show stopper but just as well to point it out :-)

Cheers

Andy

Hi all,

thanks for the report. Do not know how that slipped through but we have updated the download.

---

New version, changes:

[BUGFIX] Server: Fixed and issue with the Service Condition and remote computers

---

New version, changes:

[BUGFIX] Server: Fixed Variable issue referring to a specific TaskProcess.Result
[BUGFIX] Client: Fixed "Get full output" issue (button disabled even though more output existed)
[BUGFIX] Server: Fixed an issue with loading referenced libraries in Unmanaged dll call Task

---

We tried upgrading to 6.1.1 (from 6.0.9) and it appeared that our SQL tasks (towards an Oracle DB) suffered from this.
The tasks started exit with the error: ERROR [IM003] Specified driver could not be loaded due to system error 998 (Oracle in OraHome92).

The tasks worked well in 6.0.9 and appear to work well in 6.1.0. Also I tried testing the SQL connection in 6.1.1 and it tested ok.

Right now I am at 6.1.0, so extensive testing is not possible.

Best regards,
René

We tried upgrading to 6.1.1 (from 6.0.9) and it appeared that our SQL tasks (towards an Oracle DB) suffered from this.
The tasks started exit with the error: ERROR [IM003] Specified driver could not be loaded due to system error 998 (Oracle in OraHome92).

The tasks worked well in 6.0.9 and appear to work well in 6.1.0. Also I tried testing the SQL connection in 6.1.1 and it tested ok.

Right now I am at 6.1.0, so extensive testing is not possible.

Best regards,
René

Hi René,

1. is your system 32 or 64 bit?
2. Can you verify if the VisualCronService.exe is running as 32 or 64 bit?

---

I am running 32-bit.

A problem we have seen introduced in 6.1.0 is that suddenly using loopvalues in conditions doesn't work:

A) Select 4 columns from DB
B) Loop the output in A)
B1) Echo {LOOP(CurrentValueXArray,3)} (this works fine)
B2) Condition: If {LOOP(CurrentValueXArray,3)} contains xxxxx then skip this step.
Write to file: {LOOP(CurrentValueXArray,3)}
B3) Echo {LOOP(CurrentValueXArray,3)} (again - simply because it's fun)

Now what happens is that even if {LOOP(CurrentValueXArray,3)} is xxxxx it is written to the file.
In 6.0.9 the job worked fine.

I haven't tested this in 6.1.1 since the bug mentioned in previous post keeps me from upgrading.

A problem we have seen introduced in 6.1.0 is that suddenly using loopvalues in conditions doesn't work:

A) Select 4 columns from DB
B) Loop the output in A)
B1) Echo {LOOP(CurrentValueXArray,3)} (this works fine)
B2) Condition: If {LOOP(CurrentValueXArray,3)} contains xxxxx then skip this step.
Write to file: {LOOP(CurrentValueXArray,3)}
B3) Echo {LOOP(CurrentValueXArray,3)} (again - simply because it's fun)

Now what happens is that even if {LOOP(CurrentValueXArray,3)} is xxxxx it is written to the file.
In 6.0.9 the job worked fine.

I haven't tested this in 6.1.1 since the bug mentioned in previous post keeps me from upgrading.

Could not reproduce this in 6.1.1. Still I find it strange that you get this. Have you enabled "extended debugging" on the Condition set. Running the Task again with that enabled gives some interesting info to log file.

Also, we find it very strange with the Oracle problem. If you compare the files for System.Data.OracleClient.dll you will see that we use the exact same file. And we have used this and the same code for SQL execution for a year.

---

We tried upgrading to 6.1.1 (from 6.0.9) and it appeared that our SQL tasks (towards an Oracle DB) suffered from this.
The tasks started exit with the error: ERROR [IM003] Specified driver could not be loaded due to system error 998 (Oracle in OraHome92).

The tasks worked well in 6.0.9 and appear to work well in 6.1.0. Also I tried testing the SQL connection in 6.1.1 and it tested ok.

Right now I am at 6.1.0, so extensive testing is not possible.

Best regards,
René

I quickly searched the Internet. It seems like you are using ODBC instead of the faster Oracle Direct? Is that true?

IF you use ODBC the most common error is if you use a User DSN instead of System DSN. User DSN is not shared normally. Are you using a Credential?

---

I tried upgrading back to 6.1.1 and it appears that the "condition"-bug reported is not there, and also the SQL bug appears to be gone. At least for the moment. :-)

We are not using ODBC connections, but using the VisualCrons connection-handling (if this is what you mean by Oracle Direct)? But it may be that VisualCron is using ODBC drivers. I don't know this.

If I notice new strange things, I'll get back to you, but for now you can ignore these bugs.

I tried upgrading back to 6.1.1 and it appears that the "condition"-bug reported is not there, and also the SQL bug appears to be gone. At least for the moment. :-)

We are not using ODBC connections, but using the VisualCrons connection-handling (if this is what you mean by Oracle Direct)? But it may be that VisualCron is using ODBC drivers. I don't know this.

If I notice new strange things, I'll get back to you, but for now you can ignore these bugs.

In the Connection you select if you want to use ODBC, OLEDB or Direct mode.

---

ahhh...now I see. Well, we are apparently using ODBC.

I will test using Direct mode, if such should be more stable and faster.

Thanks.

Ok.

1 day since upgrade to 6.1.1 and our ODBC SQL connections get the IM003 error.
Today all the sql tasks were updated to use a direct Oracle connection, and now they seem to work.

However - this doesn't change the fact that there is a change/error somewhere between 6.1.0 (which seeams to work) and 6.1.1.

Secondly - I was still getting the bug that using loop-values in the condition has appeared in version 6.1.0 and also exists in 6.1.1. The jobs worked fine in 6.0.9.
In 6.1.1 I have now changed these jobs to echo the loopvalue and then use this output in the condition instead of the loopvalue. But this is a hack.

So - sorry guys - you still got bugs. 🙂

Ok.

1 day since upgrade to 6.1.1 and our ODBC SQL connections get the IM003 error.
Today all the sql tasks were updated to use a direct Oracle connection, and now they seem to work.

However - this doesn't change the fact that there is a change/error somewhere between 6.1.0 (which seeams to work) and 6.1.1.

Secondly - I was still getting the bug that using loop-values in the condition has appeared in version 6.1.0 and also exists in 6.1.1. The jobs worked fine in 6.0.9.
In 6.1.1 I have now changed these jobs to echo the loopvalue and then use this output in the condition instead of the loopvalue. But this is a hack.

So - sorry guys - you still got bugs. :)

About the Oracle error. We have not changed any code in this Task since 2011. This might be related to permissions. Are you using a Credential on that Task? Or perhaps you ran the VisualCron as another user before?

Didn't you test the loop/condition bug in an earlier post and said it was OK? What is not working now?

---

Hey.

Regarding the Oracle error then I have no answer. We don't use credentials on SQL tasks, and as I said: it worked fine in 6.1.0, but not in 6.1.1. As a developer I also know that it is sometimes it's not easy to have an overview of all the dependencies in these complex systems.
Anyways - I have updated my tasks to run Oracle direct, which works.

Regarding the loop - yes I previously mentioned that it worked fine, but apparently I was too hasty. After a restart of the VisualCron service the error started appearing in the job I was testing on.
So my suggestion is to create the job as mentioned above - restart the visualcron service - and see if the bug appears.

I am sorry I cannot be more of a help in finding a solution.

-René