DSXchange

You ended up posting this three times. Please delete the other two before someone replies to them. This one you can't because... well, because I've replied to it.

What's your target? If it's something updatable (like a db table) then you could load the data as is and if '02' is detected, issue an update post load.

You'll need to make two passes through the data, once to check for the '02' model and a second time to make the changes if you find one. That check can be a another job or a script as noted, if you've landed the data.

I'm curious why you built a 'check pointing' system for your job sequences when that functionality is already built in?

Clear but fatally flawed. :? You need to understand that 'before job' does not mean 'before the job starts' just like 'after job' does not mean 'after the job finishes'. In both cases, the job is actually running when those sections trigger but one is before the objects on the canvas are started and...

You'll need a mechanism to record the latest commit point and then another mechanism to check that (typically via a contraint) so that you only start 'processing' rows once you are past the previous commit point. A successful job run would set that to zero. Of course, all this assumes a static source.

Sure, because when it is 'coming in from the source' it is just a string value you want to load into that field.

Sreenivasulu wrote:Restartability of sequence does not work as desired. This view is based on my experience.

And based on my experience it works exactly as desired.

There is a huge difference between restarting a Sequence at the failure point and doing the same within a single job. The former is an automatic feature of checkpoints while the latter needs to be explicitly coded into your job.

You are converting a string to a decimal and your string can potentially hold more data than will fit in your decimal. It is alerting you to that fact.

Bad path. Permissions.

I doubt it does. The job may be 'running fine' but is it processing any records? Are all the fields in your flat file defined as Varchar?

That or the file is empty.

You really need to be taking these concerns / questions to IBM. Horse's mouth and all that.

That difference is documented as well.

100 records doesn't sound all that huge to me. :wink: Server can easily process millions of records in a single file, can't imagine PX would have any issues but it can depend on exactly what you're doing. I would also be curious what issues you are facing with your large files, perhaps a better solu...