Friday, February 24, 2012

Does a checkpoint file record a package's state

The state of a package at any one point in time is determined by the values in all of its user variables as these are the only properties in the package that can be changed and persisted throughout the runtime of the package.

Is the package's state stored in a checkpoint file in the event that the package fails? In other words are the user variable values stored in the checkpoint file?

Thanks

Jamie

Can task A update an enivornment variable i.e. persist the state outside the package.

Out of interest viw does package B need to update a variable in package A.

|||

SimonSa wrote:

Can task A update an enivornment variable i.e. persist the state outside the package.

Not in this scenario!

SimonSa wrote:

Out of interest viw does package B need to update a variable in package A.

[I presume that word was "why" :)]

That's a question that needs to be answered at length - preferably over a few beers!

-Jamie

|||

Jamie,

Can you ellaborate on what this variable (PkgA) represents (I.E., some sort of count, threshold, clock/time, etc...)?

We've had scenerios where a variable needed to be updated and couldn't be done using a GLOBAL_ENV_VAR or some other global, it needed to be updated per client(job), and client(job) specific function. So what we did is created and modified text-based files to update the variables values.

Say for instance, you had to update variableA (which was a boolean true/false), you could create/modify a file specifc to that instance/job run, and change the "variableA=" to true of false. Then you could always refer back to that specific file to lookup the values - like creating your own checkpoint files.

|||

Jason,

The particular one one in question was a variable called PackageStack which maintains a comma seperated list of packages that have been called, in the order that they have been called.

Each package has an OnPreExecute event that "pushes" the name of the package into the PackageStack variable and an OnPostExecute event that "pops" it off.

-Jamie

|||

Similarly, you could log this using a log provider, however, you will run into the same problem I am facing - with that logging bug and only logging the immediately inherited pkg!!!

Maybe, whom ever answers this post can solve both our problems...

|||

Yes, the values of the variables are stored in the checkpoint file.

K

|||

I disagree, I believe this is only true for simple variables. I have stored a recordset in a variable and this wasn't stored in the checkpoint file.

Either object types aren't supported or there is something about what is saved.

What happens if a variable is changed in a loop. What is stored in the checkpoint, the variable value at the start of the loop or the value at the point of failure.

|||

Correct, object types are not stored.

ForEach loops start at the beginning of the collection.

For loops continue where they left off.

They all key off of the variables.

K

|||

KirkHaselden wrote:

Correct, object types are not stored.

Why not?

Will this change?

-Jamie

|||

I've just come across a differrent "problem" with this.

I have 2 packages pkgA and pkgB. pkgA calls pkgB

pkgB has 2 tasks taskA and taskB. taskA is a script task that updates a variable (varA) in pkgA. taskB is a data-flow that is failing.

pkgB uses checkpoints

Now, I can correct the error that causes taskB to fail but the problem I have is that when I rerun it using the checkpoint file taskA will not execute and therefore varA will have the wrong value in it.

There isn't a way around this problem currently but is there a way that this could be catered for in the future using checkpoint files? i.e. The checkpoint file for pkgB would have to store the value of varA even though varA is in pkgA.

-Jamie

No comments:

Post a Comment