6.1.1 - VisualCron - Forum

Community forum

Support
2012-04-27T10:02:06Z
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
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
osirisja
2012-04-30T15:30:01Z
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
trevinom
2012-05-01T12:53:41Z
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.
osirisja
2012-05-01T13:24:37Z
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
Support
2012-05-01T20:31:20Z
Hi all,

thanks for the report. Do not know how that slipped through but we have updated the download.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Support
2012-05-02T06:58:20Z
New version, changes:

[BUGFIX] Server: Fixed and issue with the Service Condition and remote computers
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Support
2012-05-04T08:18:21Z
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
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
hawkings
2012-05-11T07:32:24Z
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é
Support
2012-05-11T12:32:24Z
Originally Posted by: hawkings 

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?
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
hawkings
2012-05-14T07:32:19Z
hawkings
2012-05-15T06:58:02Z
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.
Support
2012-05-15T09:48:39Z
Originally Posted by: hawkings 

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.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Support
2012-05-15T09:52:20Z
Originally Posted by: hawkings 

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?
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
hawkings
2012-05-15T10:54:32Z
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.
Support
2012-05-15T11:55:30Z
Originally Posted by: hawkings 

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.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
hawkings
2012-05-15T12:55:03Z
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.
hawkings
2012-05-16T10:25:21Z
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. 🙂
Support
2012-05-17T10:18:15Z
Originally Posted by: hawkings 

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?
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
hawkings
2012-05-18T11:38:46Z
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é
Scroll to Top