DSXchange

mac4rfree85 wrote:I tried the following but it was not converted.

You quoted the char functions you were attempting to use so they just turned into a 14 character string.

I've seen it take anywhere from 10 to 30 minutes sometimes to clear ports in a WAIT state... how much time had passed when you posted?

Any I'd have right now would be Informatica related.

Perhaps an exact search of the forums for JOBINTERIMSTATUS would turn up something useful?

Yes, jobs must abort for the checkpoint restart to work.

Create an after-job routine that checks JOBINTERIMSTATUS which shows what the final status will be at that point. If it says that it will be finishing with warnings, abort the job by calling DSLogFatal() with an appropriate message.

But that's the question, "in between" or "within". What you cannot do is define a job parameter (let's call it B) and for some portion of B you reference another job parameter - let's say A:

Parameter A: "1"
Parameter B: "100":#A#:"002"

No, you cannot. Multiple levels of parameter "resolution" are not supported.

Not possible. Column values can come from your data stream but not table or column names. You could use a job parameter for that but it wouldn't help in your "update different tables without looping" quest.

And yet we all know that active stages in Server jobs report the errors regardless of what actually caused it. Was there a "From previous run..." entry added after you Reset the job?

What did your official support provider have to say?

Out of curiousity - do you truly need a stored procedure? What would it be doing that you could not do in the job?

I've basically done exactly what Ernie suggested for the first one in the past and it worked out fine. We were using the Trigger Column option in the XMLOutput stage which means we had minimal control over the names created, so had to go back and post-process to convert them to the client's standard...

One option might be an after-job check that deletes the file if it is found to be empty.

No, an output file is always created.

All that's stored in the most recent set of stats, if you need more you need to capture and store them. Elsewhere.

Be very careful if you take this "edit the dsx" route to change job categories. One slip of the editor and the import can destroy your project. Been there, done that, got the t-shirt.