DSXchange

Welcome! Sorry to see you here for the first time with a problem like this. A handfull of points - a) If it's truly urgent, call your Support provider. Not everybody checks the boards all the time, or lives at the other end of an RSS feed. b) You got a coredump from your job, which means it blew up ...

Here's what REALLY matters. By the time this happens:

A) Does anybody notice?
B) Are you still there?

Kidding, of course. Sorta.

I'd amend one of your statements to: "You document the method used and what could happen."

Another possibliity!

Create a 'local' copy of the table (perhaps in your own schema / workspace) and populate it with only 100 of the rows from your source table. Fast and easy to work with it when it's bite sized.

If you used Job Parameters, I'm at a loss as to why it would 'keep on changing' while the job runs. Don't use Job Parameters, use a Stage Variable. Check your online help for @DATE and @TIME which can be one way to get what you want. Either that or the DSJobStartTimestamp macro. Here is the importan...

Yes, you'll need to account for all of the columns so you can check to see if any have changed. Sounds to me like you need to include your six columns in whatever kind of reference lookup your are doing. Then, when the record already exists you can check your six fields to see if at least one of the...

There's no magic bullet. You will need to create a process to compare one row to another, just like you would with any other 'tool' or database. A couple of suggestions off the top of my head: Drop the output to a flat file and then use your O/S to remove the duplicates. For example, from UNIX you c...

Interesting. Up to this point, all I've ever done is use them to "pass" information between coordinated routines, so have yet to stumble across the issue of them staying red in the Transformer. Good to know. I was concerned that the OP was trying to use them exactly as typed in their message and, wh...

If this "import" is actually a promotion activity, i.e. bringing the latest version of the job into Production from test, then consider using Version Control... unless somehow you can't use it for PX jobs. It will preserve the old logs.

Simply put, no - it's not possible. I would suggest you attempt to further optimize your query. If a subquery (correlated or otherwise) is too slow, then consider using an inline view to "run" your first query and then join that to your second query. Of course, it's hard to make useful suggestions w...

Never hurts to search the forum first! Chances are someone else has already had this question (or at least a very similar one) asked and answered.

For example, check out:

http://www.dsxchange.com/viewtopic.php? ... =week+year

Hmmm... that's kind of a big question and the answer could vary based on your knowledge of DataStage. High level: The answers you seek, Grasshopper, are all in the log. As each stage is "closed" (in the reverse order they are opened, BTW) the number of rows they processed are recorded. There are sev...

Ray had told about the usage of system variables @User0-@User4.So out of curiosity I tried to use them but failed. Actually, what Ray mentioned was the use of @USER0 - @USER4. As with practically All Things DataStage, case is very important. If you literally tried using @User0 and got your error, s...

Has it been installed yet and is this a 7.x version?

In case anyone cares what the answer is to this, this is (paraphrased) from Ascential Support. Note that this apparently applies to the 7.x release specifically, the 6.x release was meant to work this way but apparently... doesn't. You cannot install DataStage on a server with more CPUs than you are...

Break the third field up into four separate fields before you hit the Pivot stage. Simplest way to do that would be with the FIELD function.