DSXchange

Any stage can be on the other end of the output link from a Change Capture stage.

Zero rows might be output in some circumstances, in particular where the two inputs to the Change Capture stage are identical, at least in those columns for which change is being detected.

Clearly everything is NOT correct, otherwise you would not get this warning.

Have you performed a Search for this message?

Is CACTIVE a key column? Is the CACTIVE column on both input links or only one?

Is CACTIVE a column on the output link? If so, how is it derived (check the Mapping tab)?

How (and when) did you get the elapsed time for the stage? Be aware that you will only get times reported as at the sampling intervals; elapsed time is not a continuous measure. Statistical error may be quite large for short intervals. If you regard this as resolved, please mark it so using the gree...

Open the job in Designer and inspect them.

Try using "CAT" insead of ":". It's a synonym for the concatenation operator. At worst there IS a server function that you might attempt to try; Cats().

If the arithmetic operators work and the string operator does not, then it's a bug as far as I'm concerned.

Have you done a Search? I'm sure this has been asked and answered previously.

Scale = milliseconds. Maybe the earlier version was not as rigorous in checking. Adjust your scale to match what's really out there or, even better, re-import the table definition and use what comes in.

Had you set up the user (perhaps isadmin) as a valid Windows user before performing the installation? That is what I did, and I have a successul installation on Windows XP. The number of times you need to run install.exe depends on which options you elect to install - if you elect to install everyth...

Your understanding is correct. DataStage does not have an internal representation of timestamp in server jobs/DataStage BASIC. I tend to use a delimited represenation, for example 14788\10360, where the bit to the left of the delimiter character is the date and the bit to the right is the time part....

Poor choice of stage type. Use Complex Flat File stage. It handles packed decimal data much better.

Moderator: please move to Parallel forum

There is a way, but you're going to slow down execution considerably if you try to capture this information while the job is running. CPU consumption is captured periodically and recorded in various records in the repository table RT_STATUSnnn for job number nnn. So, however you do it, you're going ...

Is the database on the same machine. A quad processor might be able to consume more resources IN THE DATABASE, leaving less for the hashed file that the dual processors on the development machine could provide.

DataStage itself has some really useful built-in Transforms, particularly MONTH.FIRST and MONTH.LAST. These will go a long way you solving your not-very-well-specified problem. We don't really know, in a general sense, what problem you are trying to solve.

DataStage will support as many as you have hardware resources to support.

Explicit sort may be even better here, because you have the "don't sort, already sorted" capability that lets you perform sub-sorts.

Indeed the only time that CLEAR.FILE can hang is if there is some obstacle to it operating - either the file being open (by any process) or any process owning an update lock of any kind in the hashed file.