DSXchange

Similar != same. Please start a new post when you have an issue. ps. I've split you out and linked you back to the post you chose.

Delete the underlying assets as well, the Dictionary file you noted and the hashed file itself.

Please don't encourage him.

So... what are your thoughts on this? What have you tried so far? To me it looks like a normal horizontal pivot with an extra check for repeated values that should be constrained out of the flow. All except for the last one where it makes it look like you need to sort the output before the duplicate...

I'll be the first to admit I have zero experience with SQL Server and I don't see any documentation for that stage in my 8.5 docs. However, it certainly couldn't hurt to try whatever you'd like to try to see if it helps. Hopefully someone familiar with SQL Server access on a UNIX server can chime in...

As noted, I do not believe there is an SQL Server stage in a UNIX DataStage server which is further confirmed by your error message: "Operator sqlsrvrread does not exist in the registry". You'll need to remove whatever remains of that stage from the job and replace it with whatever would w...

The point being made is that there is no SQL Server stage equivalent on the UNIX side, it is a Windows only product. You'll need to use a different stage, like ODBC.

Why do we have two topics on this one issue?

Pick one and stick with it. If we continue to thrash back and forth, I'll lock one. Eeny... Meeny... Miny...

<corrected>

Yes, one of the dsjob run modes is RESET.

You don't need to clear them, any deleted hashed files will simply be recreated the next time the job runs that writes to them. Yes, even if that option isn't specifically checked.

You can't use VARCHAR in a fixed-width file, it maketh no sense. Switch it to a CHAR.

Leave it blank, which (essentially) makes it a constant.

Stage variable svCR, set Intial Value to CHAR(13) and then concatenate the stage variable into your strings. You sure you don't need a LF or CR/LF pair instead?

You can use those functions as long as you are careful of the partitioning. Or read the record as one long string and parse out the individual fields after stripping the header/footer records, perhaps with a substring check.

Typically one would do that by recognizing them and not passing them out via a constraint. Usually the first few characters can identify them, is that the case for you?