DSXchange

(hint, hint) what? Re-read what you posted. There was no hidden 'suggestion' from Ray because you did not indicate you were having any kind of problem. I had to get the transformer from a previous version of the job and then it was fine. Even your followup post only seemed informational. There were...

Post the 'command' you are executing. If it is a batch file or script, post that as well. NOTE: You've marked your OS as 'Windows' but mention using the 'cat' command which is typically UNIX. Which is it?

Then stick with the hashed file reference lookup. There is no 'datastage' problem here, but a problem with your job design specific to how you setup the OCI reference lookup. To get that working correctly, you'd need proper sql to constrain your query based on key values in your input stream - like ...

Nagin wrote:

narasimha wrote:Re-compile your routine ClearHashFile and try if it works.

I tried re-compiling the job I am still getting the same error

He did not ask you to recompile a job but to recompile the ClearHashFile routine. Is that what you did?

You don't have any kind of Julian date. Why is that particular error being reported?

If you log in with the second address, you can directly copy the web address and post as the Url link. But if you have logged in using the first address you will need to put in the the www. before dsxchange.com while giving reference to the URL links. We've had this conversation before, but it's al...

No, as that's a perfectly valid timestamp. He posted the issue: "Trans_Date_Dim_datatypes,0: Conversion error calling conversion routine timestamp_from_string data may have been lost" I assume that's because you are going from a 100 character string down to a 19 character one. I'm assuming you need ...

DSguru2B wrote:Its the second box in execute command stage.

Yep - and (oddly enough) it's labelled Parameters.

my user defined query is below SELECT DIM_ZIP_CODE.ZIP_CODE_KEY,DIM_ZIP_CODE.ZIP_CODE FROM perform_owner.DIM_ZIP_CODE WHERE rownum < 200 So... for every record through the job, you are going to select the exact same set of 199 records and then return only one of them? Over and over. You sure that's...

Your user-defined sql is invalid. Specifically, the bind variables don't match up to the columns in the stage. Why not let the stage generate the sql?

You'll never get 'SUB' from that routine because the second if-then-else stands completely separate from the first. So, all you'll get is 'UNSUB' or 'NULL'.

Your UNIX-based DataStage server needs to be able to 'see' your local drive in order to access files on it. You'd need to arrange an NFS mount or use something like Samba to enable that.

Only thing to add is the value is set to 0 'after job' with a successful run. Or you can just nuke the checkpoint source.

I take a different approach and write out 'commit point' row numbers during the course of a run. Last value is used to constrain during restart.

Yes, you shouldn't 'need' to, but I always do - seen too many times where 'odd' behaviour was corrected by the explicit inclusion of a transformer stage.