DSXchange

gateleys wrote:And can you provide a link to your website also, please!!

At the bottom of every one of his posts.

Via the Director's 'Add to Schedule' option, no script needed.

It's not available in Server. We've had to script changes into the .ctl file 'on the fly' before the actual load using 'sed' to handle things like that.

Or let it generate a .ctl file and then use your own (static) pre-edited one during the load.

That's normal behaviour for the Oracle bulk loader. You need to use the 'PRESERVE BLANKS' clause if you want them retained.

Yes, you'll have balance the commit and rollback issues. I've done this before but always with a commit level of zero - all or nothing - so it is all done as a single transaction across the FK'd tables. A lack of UNDO space then becomes a DBA problem.

I understand your point, Ken. In most cases, yes - split the two and power load them separately. Just wanted to point out that in this (seemingly small) case, using one OCI stage would do the trick. And no 'transaction grouping' needed as that would force a commit level of 1 for a net gain of zero. ...

What problems? Using one OCI would solve all of them in one swell foop.

There is no 'DataStage Scheduler', it leverages existing O/S mechanisms. On UNIX, that would be 'cron' - specifically, the crontab of the user that did the scheduling is where you would find the information.

Hack at your own risk.

Would be good if you answered the question re: Are you using parameters? They will work before job but not necessarily in a Command Execution stage, hence the question.

Odd. Tells us you should report it to your support provider. And don't worry about reinstalling the client - it won't break or reset anything, simply fix anything that may be wrong. You still should give it a shot.

Peter - use a single OCI stage rather than two separate ones. That way all your transactions will occur as a single 'unit of work' and you won't have to commit on every record.

Are you using job parameters in the command? It can look good in the log but not translate them in the actual command that is run...

Then something is definitely... how do you say? Broke.

I would report this to Ascential support. What exact version of Datastage and on what platform, btw?

Did you get a chance to try your test and see if anything is being comitted yet?

Are others experience this or just you? Have you tried reinstalling your client? It's kind of like giving advice to 'reboot your computer' when something flakey is going on, but you'd be surprised how many times that fixes things.