DSXchange

Or just spell "OBJECTS" correctly.

OK... start with the simple stuff. Does the directory exist? Does your user have write permissions to it?

A search for DS_AUDIT here should turn all of that up.

Right, it's all about the job design and the resources you are leveraging - disk, database, etc.

Set $APT_DISABLE_COMBINATION (should be close) to True and rerun so we know where the error is really coming from.

No, there's no magic setting for that. You may, however, be able to make the job "multi-instance" and run multiple copies, each handling a portion of the data simultaneously.

So what are your rules when there is more than one record in the 'File1' file? Or when there are multiple files? Your rules are still unclear.

Not sure why you couldn't find anything and the date functions haven't changed for PX so this is valid for any version:

DateFromDaysSince()

That is extremely odd but at least you have a workaround.

That's what you get for clearing the exciting rows.

You can't use the IsNull() transform function there, but rather you need the proper RetrieVe syntax. Try: PROCESSED_FLAG IS.NOT.NULL I think that's what you need off the top of my head this early in the morning.

I'd run this by the SysAdmin, whomever administers that system, to check how SMTP is setup on that server.

And, out of curiousity, what exactly were your search criteria?

@FM represents a Field Mark, something the EC stage adds because it is actually returning a dynamic array rather than a simple string. That strips any by converting them to an empty string.

Since you didn't explicitly say, what character set does your target Oracle database use?