Please note that VisualCron support is not actively monitoring this community forum. Please use our contact page for contacting the VisualCron support directly.


Joan
  •  Joan
  • No customer Topic Starter
2012-08-20T06:56:21Z
When viewing or editing task details, if the GUID were visible, it would save having to open and click through the "Variables" pop up.

For example, I am building a lot of jobs and tasks and would find it easier to open a source task and grab the GUID to use as a variable in the subsequent task that I am editing. You could extend the idea to showing a drop down of all the possible variables for the task using a 2 column drop down.
Sponsor
Forum information
Support
2012-08-20T11:52:14Z
Right, this could help. But please try to avoid using the Guid and make it more general instead.

Instead, to make it more general you can use:

PrevTask - always point to the previous Task
Active - - always point to the current Task

Also, if you open the Variables browser (from a Task) and go to Job->Tasks-> you will see the list of Tasks and can open them to see Id etc.
Henrik
Support
http://www.visualcron.com 
Please like  VisualCron on facebook!
Joan
  •  Joan
  • No customer Topic Starter
2012-08-20T23:34:48Z
I'm using the variables browser from the task editor and that's the item I find a little clunky. I don't have any suggestions on how to make it less clunky so i thought I'd make a suggestion for an alternative.

The job I'm working on has 7 tasks - it behaves like a standard SSIS ETL task.
1. Identify the data flow task by name and set the CET (current extract time) datetime. Return the data flow id, LSET and CET values.
2. Insert event record and return the event id.
3. Clear the staging table data - SQL task
4. Import data - SQL task to run a stored procedure - return some row counts - on error go to task 7. Stored Procedure parameters include CET and LSET from a loop on task 1 output.
5. Update event log - loop on the row counts and use the event id from task 2 and return the event log row
6. Update LSET (last successful extract time) in data flow table - uses the data flow id from event log row returned task 5.
7. Exception handler - update event log with various items from task 4 - Name, StdErr and ExitCode as well as the event id from task 2.

One strange thing is that when I force the stored procedure in task 4 to raise an error, the job doesn't go to task 7 even though I have set task 4 "on error" to go to that task.

I can't see how I can avoid using GUIDs altogether.
Scroll to Top