DSXchange

In server jobs you design it like this. ---> Transformer ---> database (ODBC, DB2, etc) | [Reject] | SeqFile Within the Transformer stage there is no constraint on the output link going to the database, and there is no constraint on the output link marked as handling rejected rows (a check b...

Quite simply that's not how DataStage works. It can't be done with any tools that Ascential would regard as "legal", and is very difficult and may void your warranty by other means. Table definitions are link properties. If you change the properties in a job you have to recompile the job, so that th...

This is probably a permissions issue on the DS_LICENSE hashed file in the DS Engine account. When you connect, your Windows identifer string and UNIX process ID is used as the key to this hashed file, as an indicator that you're connected (and from where, which can aid tracking down who's connected ...

Hi - Not that my input has anything to do with this matter - it is just a curiousity. Even though you use encrypted for the parameter containing the password you can easily decrypt it by making a job with some source --> transformer --> flat file (having at least one row going through this transfor...

Avoid the second WITH. You'll get better query performance, particularly if the two date columns are indexed (which, ideally, they should be).

Another vote for "do it now". There'll never be a better time. There was, but it's gone. Parameters buy you insurance against things that may change over time or between environments, such as pathnames, data source names, passwords, WHERE condition constants. Best practice is to have default values ...

If your job has this design: SeqFile --> Transformer --> SeqFile then your job log has an "active stage finishing" event in which the row counts from the input and output links for the Transformer are recorded. This can be inspected from Director, or retrieved by the DSGetLog... functions.

It's even there for DS 5.2.1 (in on-line help), so maybe it's an intrinsic function for job sequences. I'll have to do more investigation.
However, re-reading your error message, the caret isn't under the DSWaitForJobList token, so it's probably not that.

Capture field3 into a stage variable, with a preceding stage variable to detect whether the value in field3 has changed. Accumulate the concatenated string in yet another stage variable. Constrain the Transfomer output to generate output only where the value of field3 changes (and @INROWNUM <> 1). M...

Excellent response!

Therefore, as an expression:

Willo wrote:Cheers guys that code works, I was tempted by chulett's suggestion of trimming the timestamp but that would be cheating!!

It's not cheating, since DataStage is a "data type free environment".
And it may be quicker!

How much are you prepared to pay for "expert comments"? As far as I can see, the principal abnormal behaviour has been in the database server. The second abnormal behaviour is your expectation that DataStage can continue to load a table when the database server crashes and a complete recovery has no...

Thanks Ray for pointing out that... I have tried out the method suggested for this...i am able to get the results in a single row, BUT have a small problem of writting the output. input file: 4.8,"1985-01-01",100871,3.2,"1985-12-31" 58,"1985-01-01",100890,46.4,"" 54,"1984-06-01",100890,40.5,"1984-0...

Try switching back to generated SQL (yes, I know you lose the RTRIM and NVL functions, so preserve them first, if only by copying to the Clipboard). See what DataStage generates. Can you spot anything from that? Columns specified as key go into the WHERE clause in the generated SQL, while columns no...

Try SET SOURCE_SYSTEM = '?' and so on. This column (based on the data at the bottom is a character string, and so should be quoted. Similarly, the result of RTRIM() is a character string, so parameter markers for these must be quoted. However, CUST_NBR is not a character string so its parameter mark...