DSXchange

Can't speak to the Exadata question, but don't bother with the 8.0.x release. If 8.5 is available for your platform, go for that, else the latest 8.1.x release.

I'm assuming he means something more... official. A button, perhaps.

Seems like you need to get more RAM installed. Do you have a machine with more than 2GB you can try it on? I couldn't find minumum specs for the client software online, only for the server component.

Job design ! I told you already: Oracle OCI ---> Transformer -----> Oracle OCI And where exactly did you already post this information? :? There are many sides to this equation and how long the select allegedly takes is only a part of it. Add a constraint to your transformer and set it to @FALSE. T...

Post your job design. Have you done any tests to determine the bottleneck?

Comparing Toad to DataStage is an 'apples and oranges' discussion.

Don't have any access this year and can't check. I suspect the first is the 'design time' value stored with the job and the second is the value stored in the 'values file' but hopefully someone who knows for certain will wander by.

Can't check right now but you should be able to schedule a job to run on 'every' 5th day of the month. Worst case, you can 'Add to Schedule' and pick November 5th, then 'Add to SChedule' again and pick December 5th, etc etc etc.

Because you specified it correctly in the second example. Parameters that are part of a parameter set need to be referenced / prefixed with their set name for them to fully work as expected.

There's also the FMT function, from what I recall.

No... that would be bass-ackwards and there's no need for the 'in-band' null value here, since nulls are allowed.

No, just simply do an if-then-else construct: if the incoming field is null then send through that incoming value unmolested, otherwise use the StringToDate() function.

We're going around in circles here. :? This is meant to be the "null" date for your target column that does not accept nulls, yes? If so, where is the implementation of the "default" date that was mentioned earlier? The earlier post where you said you were setting them to "1...

As requested, post the syntax for step #4. That's where things are going wrong.

this is the view when I see in view of DB2 stage for one field but when I view the same field in the table I can view it in proper way like..9999/12/31. There is no 'proper' way. Both are correct, it's just the external presentation that is different and as noted the stage is throwing in the stored...

suryadev wrote:but when I view the records in the DB2 stage (target)

I see all the records appear like... 233673524 (9999/12/31)

And... ? There's nothing wrong here.