DSXchange

I have experienced it in 8.1.

Don't the rules files have to be in a specific folder? (Don't have immediate access to QualityStage at the moment, so can't check.)

Don't the rules files have to be in a specific folder? (Don't have immediate access to QualityStage at the moment, so can't check.)

IOW ?

Isn't that the noise a cat makes?


Please refrain from all but the most common English abbreviations on DSXchange. Many of our readers don't have English as their first language, and it's tough enough as it is, without having to decode the mental processes behind arcane abbreviations.

Close the job, re-open it, re-compile with your breakpoints enabled. If you're really paranoid, close and re-open it again and you probably won't get "debugger client has disconnected" aborts.

I'm prepared to be you restarted your client machine in the interim.

This run-time overflow has occurred in the client software (or its underlying operating system), not on the DataStage server at all.

Isn't pita a kind of bread?

There's no consistent way to decode this. So why is it wanted?
For example 2541170 could decode as ZEBBHA.

That's only part of the problem, but the other part could be resolved by including the SKs as a non-key column in your hashed file. Of course, you then have to maintain these when a Type 2 change occurs.

... or even store the CRC32 value in the table itself.

No. The new data MUST be the driver. One useful technique is called "bucket table". In this technique you identify all the keys in source and load these into a table in your database. You can then perform a join of this "bucket table" with the existing dimension table to retrieve...

"Spot my deliberate error"

argArg1 = Arg1
Counter = 0
Ans = ""
Loop
Remove Element From argArg1 Setting Delim
Counter += 1
Ans := Counter : Char(256 - Delim)
While Delim
Repeat

OK the first part of the question appears to be resolved, now does anyone have any creative ideas about a punishment/preventative?

I prefer a fork join design, where one leg of the fork counts the number of rows associated with each key value - this is joined back to the original row and used to filter based on count = 1 or otherwise. Possibly easier is to generate a Key Change column in the Sort stage; duplicates have this set...