DSXchange

Yep sure does! Probably one or two other things you didn't know about CREATE TABLE in the following example. CREATE TABLE MyTable ( TYPE 18, MODULO 4211, SEPARATION 4, keycol1 INTEGER NOT NULL DEFAULT NEXT AVAILABLE, keycol2 DATE NOT NULL, othercol1 INTEGER NOT NULL DEFAULT 0, othercol2 VARCHAR&...

If the table definitions are in the Repository in the Hashed category, which is the default location, you're able to get them with a query on DS_METADATA. This table also has the CATEGORY column available.

The dsenv file is a script executed by all DataStage processes, principally to set necessary environment variables. The file is in the DataStage engine directory which, at version 7.x, is defined using the DSHOME environment variable. The file /.dshome may also exist, depending whether or not you're...

If you're doing a lookup to a hashed file (even via a UV stage) using the key, then it returns "that" row, not the first, not the last. In hashed files (all UV tables are hashed files), the key is UNIQUE.

OK, here we go... @ defines the default output fields for the RetrieVe query language; if there is no @ entry only the key field is displayed @LPTR defines the default output fields for the RetrieVe query language if the LPTR keyword appears in the query; if there is no @LPTR entry @ entry is used. ...

It's the system date. That's where you have to change it. Use the superuser version of the date command on UNIX, or Adjust Date/Time on Windows (you need to be an Administrator). You should be OK if you don't set the date earlier than the date when DataStage was licensed. But make sure you've got a ...

Check, too, that the TNSNAMES.ORA file is in the expected location and readable.

Ascential does not market an ODBC driver for the DataStage Engine. I doubt that the UniVerse ODBC driver would work (since the split of UniVerse and DataStage), because the UniVerse ODBC driver requires a server side component written (and compiled) in UniVerse. DataStage detects programs compiled w...

Make sure you set the "lock for update" property in the hashed file stage.

The simple solution is to declare a UNIQUE constraint on the key column of the database table.

<rant> It would help to diagnose these errors generated by helper subroutines (such as DSR_RECORD, DSR_SELECT and so on) if the error message included the other input argument values. You can get them in a server-side trace, so why not? Then you could figure out (from DSINCLUDE) what Action 3 is sup...

I almost always advocate staging after extraction and before loading. Not just for the reasons put forward by Kimball and others, and by Ken Bland here particularly, but also because this means that the "T" part of ETL can be fitted into a time window when the databases are unavailable, for example ...

I once knew a programmer who did this. Equate OTHERWISE Lit "CASE 1" BEGIN CASE CASE expr1 statements CASE expr2 statements : OTHERWISE statements END CASE Unfortunately the formatter doesn't know about it, so formats the OTHERWISE line incorrectly, which was subsequently adjusted manually.

The pdf document says DSJS.RESET, DSJS.RUNFAILED, and DSJS.RUNNING are statuses for 'a job that is in progress'. It says DSJS.RUNOK, DSJS.RUNWARN, DSJS.STOPPED, DSJS.VALFAILED, DSJS.VALOK, DSJS.VALWARN are statuses for 'jobs that are not running'. That's just wrong. The only status that a job that ...

Time to be a little bit pedantic again. The columns that are displayed by an SQL query are specified by a phrase in the dictionary called @SELECT (it only defaults to @ if there is no @SELECT phrase defined). Usually @SELECT is the same as @ but incldues the key column explicitly. But it doesn't hav...