DSXchange

Not just "should be" but can only be a single character.

Not only do you have to sort your incoming data to relieve the memory pressure on the Aggregator stage, you need to assert that sorted order in the stage itself. And lastly you have to sort in an order that supports the grouping you are doing. Only if all three steps are done properly can the Aggreg...

They have to be in the right format, not just the same to do a string compare. YYYY-MM-DD would work, yours would not. You could also use IConv() and then compare the internal dates.

You need to do an exact search, otherwise your queries seem to be date limited and don't return much of anything. But then you're right in that many of the 215 posts on the subject suggest searching, so you need to poke around in the older posts to find the wheat amongst the chaff. Here's one: http:...

I don't have any docs in front of me, so this is off the top of my head... From what I recall, the Stored Procedure stage has a property to set it to function as a Source, Target or... Transformer? Basically meant to be in the job flow and get called for every record through the job. I would try set...

Never seen hashed files cause an issue like that. As I said, in your shoes I'd concentrate on your target, the stage and Oracle client version. That and involve your official support provider for any low level fault like that.

Errors in Server jobs always come from 'active' stages, typically Transformers but that doesn't always mean they are at fault. Me, I would concentrate on the target. Did you search for your error here? You are not the first person to see that particular issue, hence the suggestion.

Ah, yes... remove duplicates. No need for a silly trailer record. And here I'd just done something similar in that other tool using a Aggregator to capture the last() record from each group.

Have you involved your official support provider yet?

No, you have to dig them up on the internet... I think Ray/Arnd may have posted a link to them but not sure it would still be valid.

I would think more messages than that would be involved here. The table could be "busy", in use by another process and thus not truncatable.

What is your actual target? Did you search the forums for that "Fault Type is 11" error message?

Any warnings in the job's log? I'm guessing you have a constraint issue, something is no longer allowing rows to leave the transformer after your change.

Well... please explain exactly what this means: "when I remove a record from the input source file" DataStage deletes are target based, not source. How are you doing this? Manually? If so, then it sounds like you are damaging the file when you do so. Lastly, I don't see how deleting a reco...

Well... let's start by having you explain what "the output table columns are dynamic" means. There's no fixed number of columns? There's no fixed column names? Not sure how that's possible unless you are creating the "output table" each time the job runs. Can you shed some light ...