DSXchange

That can't be used in directly in the stage AFAIK. You'd need to create a fixed filename and then use that 'after job' via ExecSH to rename the file to include the date.

No.

Job design? Bottleneck? The pivot is a notoriously slow stage (especially given your metrics), your issue probably has nothing to do with the hashed file itself.

You would have to read the hashed file first to check for existence and 'reject' any that succeed. You can do this all in one transformer if you don't cache the lookup or use the dreaded 'lock for update' option.

That would be because you used single quotes rather than the 'back tick' that Jim's example showed.

After all this, don't fall back on the belief that you *need* a primary key to update a record. That seemed to be the original confusion.

You need to concentrate... harder. Look closer at the output dates, especially in light of the 'SCD2' topic.

Most likely. A table name cannot be longer than 30 characters, for example.

That should be fine as long as you handle it correctly.

Those damn "they"s again and their silly requirements. Ah, well. A direct database lookup is never really the most 'performant' option. ODBC used to always be a poorer choice to a 'native' connection but I don't know if that's the case any more. It can also depend on if you are using a 'wired' drive...

Welcome aboard. :D It would be best if you told us what parts you are having a problem with or asked some specific questions. Right now, it seems as though you are looking for a 'silver platter' answer, for someone to just lay a full solution out at your feet. That's not generally the nature of the ...

For maintenance reason, my direction doesn't allow me to do directly the join in one source stage. They want an explicit design For 'maintenance reason'? You would typically only go with your 'explicit' design when you had no other choice, but with both tables in the same database, I really don't s...

It's just plain text. You can set the type as 'Encrypted' when you create them, unless you mean your own custom encryption?

Depends on the 'where'. In the database? SQL. Inside the job? Reference lookups are by definition an outer join. Would need more details to provide more help.

I've used it without NLS, so it isn't 'required' although that may be the typical implementation. It supports custom collating sequences, so I've used it when I needed (for example) to sort record types: H then D then T for Header, Detail, Trailer.