DSXchange

You can use the ODBC driver from version 5, but it has exactly the same issues. It works for 30 days, after which SQLConnect() fails with a message saying that you need to purchase a licence. The BCI functions themselves are part of DataStage, and incur no extra cost. It is a licence to use the ODBC...

Sometimes you need to quote the entire command, so as to make it a single string that can be passed to the executable. For example: cmd /C 'copy "$FILE" Dir1' The other thing that springs to mind is that environment variable references in DOS are contained within a pair of "%" characters, ...

The easy thing to do is to introduce additional output links from your Transformer stages, that can capture what's coming in.

Alternately (though it's effectively the same thing) you can use stage tracing to report the data flowing into and out of the Transformer stage for each link.

The obvious alternative, looking at your code, is to run a job that extracts the row using an ODBC stage and moves it into the user status area or into a text file from which it can then be obtained. Since it's apparently a password you're getting, I'd recommend using the user status area, so that t...

The "problem" is that the ODBC driver is licensed for use with the ODBC stage, but is not licensed for use with BCI functions. Your only solution, if you want to use BCI functions, is to obtain a full licence for the DataDirect Technologies ODBC driver. It's not a problem with DataStage, it's the wa...

I think we'll need someone with access to the Pivot stage's source code to be able to answer this one. There's no documented limit, but there's always a limit!

The output of the UNIX command includes some line-feed characters. When these are loaded into a variable (the third argument of DSExecute) the line-feed characters are converted to field-mark characters (@FM). So the actual output is something like "~1" (where I've used ~ to represent a field-mark c...

What's your alternative in server jobs?

I challenge you to do anything faster in server jobs that what can be done with BASIC expressions/routines.

Note that I didn't specify "what you can do with BASIC" - I specified "what can be done with BASIC".

Well spotted, I've edited the code.
Dots and colons are SO hard to see on a laptop monitor!

Constructing an (Oracle 9i) IMPORT script in Word, the spell checker changed TOUSER to TROUSER

You can add 183 days to the internal format, or use substrings to add six months to the date. The latter would need to be done in a routine. FUNCTION AddMonthsToDate(BaseDate, Months) Equate RoutineName To "AddMonthsToDate" Ans = @NULL Test = Iconv(BaseDate, "DYMD"...

Can't see it myself. Irrespective of the syntax the inner query must be executed and its result used in the outer query. The syntax (in this case) surely only affects where the value is stored. I might be able to be convinced in the case of a correlated subquery, where some clever caching may be use...

Can't you re-cast your query as follows? SELECT EK.EXTERNAL_SYSTEM_KEY3, EK.TDW_TABLE_KEY1 FROM EXTERNAL_SYSTEM_KEY EK WHERE EK.EXTERNAL_SYSTEM_NAME_ID = ( SELECT EXTERNAL_SYSTEM_NAME_ID FROM EXTERNAL_SYSTEM_NAME EN WHERE EN.NAME = 'ARBOR BP' ) AND EK.EXTERNAL_SYSTEM_TABLE_NAME = 'BILL_INVOI...

Yes, I have three hats.
And like to stay active on the various forums for each, mainly:

DataStage (here (where Oliver's DataStage is archived) and ADN)
UniVerse (www.u2ug.org, which took over Oliver's U2)
Red Brick (www.iiug.org)

No, temporary tables follow the rules for temporary tables; they are dropped when the user's session that created them ends.
Subsequent DataStage jobs are separate sessions.