DSXchange

Yikes, that's practically one long run-on sentence. Let me see if a little editing might help...

Somewhat. There's still a lot of "so"ing going on. Not sure what to propose at this time...

No, not for that small of a number of connected developers I don't see the point. And if your T30FILES setting was too low, you would see specific error messages mentioning that limit.

Explain to us what controls the 'number of tables' you'll be targeting or processing? Perhaps that might help people towards a solution. Also, do these tables have identical metadata?

You need to stream in your target data and do a lookup against the source to check for deletes. That or a full outer join of both sides can detect deletes in one or the other.

ArndW wrote:(note - you have two different question with the same topic, this can lead to confusion)

Note, fixed.

Yikes... way too early in the morning for brain-burners like that, perhaps later when my day is a little futher under way. Bonus points, though, for the use of "conundrum" in the thread title!

There's no burning need for those functions in a PX job, as there are perfectly acceptable String/Date handling functions already available. You just need to 'convert' one to the other.

Not possible "before job" as it's not really as "before" as you might think. The job is actually running at that point so it's too late to affect the job parameter values for that run. You need to truly be "before" the job even starts to do anything like that. So that m...

There are well established and documented APIs for getting job and log information. Check your online help's Index for functions that start with "DSGetLog___" and you'll find several for getting log information. You can also get generic information about a job, such as its last status, wit...

You certainly can create 100 jobs for 100 tables, what would be stopping you?

If you need to reuse a counter rather than increment it in the event of a reject, you'll need to 'code' for that. Makes it a little more tricky but certainly not impossible. You will, however, have to do all this in the same transformer. Meaning, the one handling the stage variables will need to be ...

So... resolved?

If that's your requirement, yes. One other 'trick' you can try is to increase the size of the fields defined in the job so they are larger than your target field sizes which would allow those 'oversized' values to actually be sent to your database. It should then do an actual physical reject of the ...

As that article notes: "These failures are due to the lock and open file limits in DSEngine being reached." and while they can get reached by the shear number of people accessing the system at the same time, more tyically these are left-over processes / locks from defunct connections. At l...

They won't be rejected but simply truncated. You'll need to check the field sizes yourself and use an explicit constraint to move them down your 'reject' link.