DSXchange

Of course. I'm just repeatedly going to get on my soapbox about the kind of sample data people tend to post and the dangers of making assumptions that it represents the whole of their reality. Or any kind of reality. Hence the repeated desire for written requirements, with transformation rules spell...

Interesting that you assume that there's always a space needed between the second and third occurrence. I understand that the two samples posted support that but I doubt we can assume that holds true for the entire run... Hopefully the original poster can clarify for us what their actual requirement...

Just want to reiterate - IMHO there's absolutely no need for any of the jobs to abort, unless of course that happens when they are actually processing data and something goes sideways. For this situation, do whatever you need to do to check to make sure all of your prerequisites are in place. If not...

Or just add a KeyChange column over Class in the Sort stage. Then just one stage variable will do:
Then just make sure your partitioning is correct or run on a single node. And keep the last duplicate.

Does the "/log" directory exist and is it accessable to your job's user?

If you are running on multiple nodes, how are you paritioning? And if so, does it work properly if you run on a single node? You could also cut this back to one stage variable if you let the Sort stage add a Key Change column. You could also leverage Transformer Looping. FYI.

Ok, some suggestions... 1. First and foremost, let us know what you've tried. 2. Tell us your version number 3. Search for other people asking the same question to see if it has already been answered. Surprisingly, you are right next door to someone trying to do basically the same thing: http://www....

If you are concatenating in a transformer, then the Remove Duplicates should be set to keep the last duplicate per class - is that the case?

It's not "blocked" - that means you've let your Premium Membership lapse, it would seem. That would explain why you're not answering my questions. [sigh]

Let me open them up for a little while...

Seems to me a good time for an XML feed so each change can be identified with a column name, no matter the combination. Guess we'll see.

Yikes. :shock: OK, let's get some more details. This 'feed', what is it - a flat file? I understand you don't know ahead of time what combination columns you'll receive but when they arrive do you know which ones you've gotten? Meaning are they properly identified with some kind of column header val...

What have you tried? What version are you running?

Because you are loading a Timestamp(6) and it needs microseconds in that case. You got away without doing it in 8.5 but could no longer in 9.1 where they've tightened things up. Something we see all the time when they fix things in later releases that were technically broken in earlier ones and a jo...

What changes? And again, an empty source will move zero records through the job so nothing will ever see your @INROWNUM constraint. I honestly don't like the shenanigans ssnegi posted when you can simply check the file before you run the job, or heck even in the 'Before Job' area as well and abort t...

Talk to your System Administrator about what that state means and what can be done about it. For some light reading, here is probably more than you've ever wanted to know about it.