DSXchange

You absolutely cannot do this in a supported manner. You cannot change a job parameter value from within a the job itself during runtime. You must use a controlling job, such as a Batch or Sequencer, to set dynamic values at runtime. There are methods to change a parameter value during a jobs execut...

Mass-compile the jobs. Or, use better job control that resets a job after it fails or prior to running.

Dates in Oracle have time information, even if it defaults to midnight. DataStage, when loading data into an Oracle DATE column, will automatically cast the data by adding a TO_DATE(...) function to the SQL.

Sure, look at Parameter Manager offered by this forums owners, or even use the hack job I wrote at my website. There's lots of utilities available but not from Ascential.

Split your inserts from your updates. Ram in your inserts. At the same time, ram in your updates into a work table with primary key index. Then, fire off a parallel dml merge query (new 9i feature) with a high-degree of parallelism requested with a minimum parallel percent sufficient to kick butt. S...

Dynamic table definitions wired into jobs - this feature is not in DataStage.

Dynamic credentials - use a job parameter in your credential fields (userid, password, server, directory, etc) and supply the parameter value at runtime via job control.

Better yet, use the hash file lookup function under the SDK folder:

If you moved the file from DOS to Unix, then you may have a Control-Z character at the end of the file. If you did a binary FTP, then it preserved the DOS formatting. Your choices are easy: 1. It's a small file, fix it using VI. or 2. If not a onetime load but you will have to deal with it repeatedl...

If you wrote a text file and put a space into a field, then what's the complaint? I suspect Dave might have selected a CHAR(1) column and wrote it to a file, expecting a NULL field when there was no source data present. CHAR(n) datatypes always return padded data, so writing it to a text file means ...

Apples and toaster ovens. A 1.4 GHz chip vs a 3.0 Ghz chip is unfair, not to mention the underlying disk subsystems are radically different. I can make a 1 cpu Windoze solution fly on a straight sqlldr direct path into a table and beat the pants off a multi-TB unix instance. But, I can't get that mu...

A direct path load will disable the indexes, the only operation left for you is either conventional load or DML loading. If you use standard INSERT/UPDATE SQL then you won't have issues with indexes, you'll instead have performance issues.

If you de-couple the building of the hash file from the reference usage later on in the logic, ie. break into 2 jobs, does the hash file error occur?

Other than the "something weird" happened explanation, I'd also make sure row buffering is turned off. I've found unexplainable errors using this on certain servers. The same job occasionally fails on one server (dev) but works fine on the prod server. Any chance you're having disk space issues? Oth...

The value you have as the id is the actual key in the hash-file that you have opted. When you drop the hash-file and recreate it, you are rebuilding the dictionary. Hence I assume that the format in which it was initially create does not adhere to the incoming record. Can you therefore identify thi...

Any caching, any multi-instance jobs all writing to same hash, or is this something really straightforward?