DSXchange

Your example is a little messed up. Did you actually mean something more like? <Department> <DepartmentId>112</DepartmentId> <EmployeeName>John</EmployeeName> <EmployeeId>101</EmployeeID> <EmployeeName>ZZ</EmployeeName> <EmployeeId>00</EmployeeId> </Department> And you need to suppress the 'ZZ' name...

What version do you have? I vaguely recall issues with the Range Lookup that may require a patch from your official support provider.

What kind of delays? Do they generally run smoothly but slowly, or do they pause at certain points for a period of time? Any pattern you've seen? I can't say what impact the VMWare is having, never used it for a Server install. You may want to ping your official support provider to see if there are ...

What stages are you using in your job? I've seen the error before, but not in a 'scheduled v. unscheduled' context that I recall.

That's not an Oracle DATE, but rather a TIMESTAMP. While the former can hold a time, only the latter can hold milliseconds. That is the root of your 'conversion error'.

If by 'filtering out the null values' you mean 'checking the lookup for success or failure' there is a Link Variable for that: LinkName.NOTFOUND which is simple enough to leverage.

There should be a NullToValue transform in there, if not it would be easy enough to create one. Check NullToEmpty and NullToZero for inspiration.

As you are suspecting, it is probably a resource issue. Are there any other warnings logged when you see this?

Didn't really want to encourage that approach... but that setting would need to be per job rather than per project. DSParams would just have the project level defaults for new jobs, so... ??

Start by declaring it as a string in the file, then validate and convert (or vice versa) as appropriate.

Yesterday's date.

Yes, that's the maximum. If your jobs don't run very often, perhaps purging based on the number of runs would be more appropriate?

Yes, it would be. DataStage is an ETL tool, not a database management tool like Enterprise Manager.

Connection timed out... firewall, perhaps?

Right, didn't say you needed to, just that you could. :wink: And I believe the OP's issue is specific to 'joining' tables in separate databases. If we just mean schemas here, then join away, separate database instances would require either a dblink of some kind (and the performance and security cons...