DSXchange

Enrol on a DataStage Administration class and you will learn the names of the tables and what's stored in them. However, the column names are deliberately left obscured for the reasons Arnd noted.

In before-job subroutine choose ExecSH and execute an echo command to write the header line. echo Employee Details > #filename# In the sequential stage name #filename#, but choose Append To File In after-job subroutine choose Exec SH and execute an echo command to append the current date as the trai...

You need to do one more step. The indexes (which are stored in I_DS_TRANSFORMS) are still pointing at the other project. You need to do a DS.REINDEX DS_TRANSFORMS command to get it right.

That's what the BCI functions are for.

Standard ISO8601 only defines dates to 9999-12-31.

DataStage conforms to that standard, as do most (though clearly not all) commercial databases.

1. No. You could also indicate the current/non-current status of dimension records using timestamp.

2. The complaint is that you must identify the dimension table key column(s) by checking the "Key" checkbox in the table metadata. Apparently you have not done so.

Can you please provide an example of what you mean? Perhaps reading them as string data types is a good workaround.

So? Using a consistent stage and link naming convention in your jobs can ease that difficulty immensely. For example contemplate suffixes such as _INP, _OUT, _REJ, _LKP (or prefixes if you prefer) on your links that connect to the "outside world".

There is no scope whatsoever for custom hashing algorithms. The supplied ones, particularly types 2, 18 and GENERAL and SEQ.NUM, work very well. They have been tuned to perfection over the years. To create a static hashed file choose a type between 2 and 18 inclusive. Use the Hashed File Calculator ...

"In Vacation" - that would also explain why it wasn't doing anything!

Not only do you need to repair DS_TRANSFORMS, but you need to realise that routines are not stored in DS_TRANSFORMS. The hashed file you need to re-index is DS_ROUTINES. Of course, if the corruption in DS_TRANSFORMS was caused by running out of disk space, then you probably need to check all the has...

You might also search for "BCI" but beware of licensing issues with the ODBC drivers from DataDirect.

I assume you're talking about a Lookup stage here.
What you say is true except if the reference input is fed by a Lookup File Set or by a sparse lookup. In either of these cases the column name must be identical. The data type, of course, should always match or at least be compatible.

You don't fix deadlocks. You prevent them.