DSXchange

Use a DSLogInfo('Output is "':Output1:'"','') to debug the error. I would be surprised if changing the quotes does anything, since they are parsed out at compile time.

Echo your input variables as well. CALL DSLogInfo('Routine input variableJobName is "':JobName:'"','') CALL DSLogInfo('Routine input variableStageName is "':StageName:'"','') CALL DSLogInfo('Routine input variableLinkName is "':LinkName:'"','')

Sort your incoming data according to S.NO and Code, then use stage variables to store the values from the previous row so that you can use your logic.

At least put in some DSLogInfo() calls to show you at whichstatement in your routine the execution is being delayed.

You can call a routine from a transform stage. The DSAttachJob() call is pretty slow, so that might bring your rows/second speed down into the single digits. The call to DSLogInfo() is not your problem, that will not cause the delay you mentioned.

Add a DSLogInfo() call to your routine that echos the input parameters, and then test that in the manager. Also, a job cannot attach to itself so if your routine gets passed the name of the actual job it will not return a value (in some versions it will hang for 30 minutes before returning nothing!)...

Truncating the decimal part is easy, either with a formatting option or a simple INT(In.Column*1000000)/1000000. But what is your rule for converting 18 digits to 10?

Ray suggested using alternate login methods, have you tried that? I usually will use "localhost" as a check as well and use a userid/password and then click on the drop-down box to see if I get a list of projects.

You will need to know (and tell us) what representation you have of that date in the integer. i.e. does it contain a value such as seconds since "12 Aug 1984 15:31" or a representation of a date such as "12081984". Depending on that value you can use a builtin function or perhaps have to write your ...

I think that somewhere in your routines you have a PRINT statement that outputs the value 38 each call.

Pankajg,

the error message was quite clear that this was the problem, but as you see it is more important to locate and solve it yourself. Good job.

The DSStopJob() call is issued from a parent process and will not work for the job itself. If you are in the After job routine there is no more processing to do - but you can terminate the job with a fatal error using DSLogFatal().

Sumit,

of course you can change the schema name at runtime - if you designed the job using parameters for the schema. Parameters are key to getting your job to access different elements (tables,schemas,instances,flat files, etc.).

What is your derivation for column po_mcptm_hutinsum? Also, the attributes for column po_mcptm_othoutsum are probably not nullable (hence the error message). You can turn off combinability mode to see if your error message becomes clearer.

Pankaj,

what is field po_mcptm_othoutsum? Is it nullable? Are you doing some sort of an operation on it? What is it's relation to field po_mcptm_hutinsum? The answers to those questions will show you what the error is and help you to correct it.