DSXchange

True but they've supplied ODBC wire drivers for SQL Server for some time now. They are there on both my 7.5.2 and 8.1 servers and are how you'd connect from a UNIX server.

OK. Try doing an Exact search for your error message(s) as this has been discussed here before. For example, a search for "check that 'dbx' and 'sed' are installed and on your PATH" has 18 matches to other posts, see if any of them help.

Did not work in what sense? What exact problem are you trying to solve again? Your RT_LOG issue sounds more like a corruption issue with the log hashed files themselves. I would suggest exporting and reimporting any job that does that to fix things of that nature.

This is one you cannot 'Test' like that, it must be executed from within a job. So create test Sequence and Server Jobs for this.

Not quite, you can use a parameter to control what "account" a.k.a. Project your hashed file source can point to.

That's normal so nothing wrong at all. Immediate Purge is the default when doing this manually.

Exactly... check into the USERSTATUS functionality to pass informaiton between jobs without 'landing' it.

Because of the associated bug related to that in 8.x, I assume?

Multi-instance jobs all share the same log and each individual invocation id run has (in essence) a view into the main log which filters out just their entries. So you need to take that into account when setting auto-purge for them.

No 'conversion' required, simply substring off just the date portion:

DSLink5.JOB_EFFECTIVE_DATE[1,10]

I'm curious why you are not using a Sequence job for this?

Ray's advice would be applicable if a stage started to look like the 'generic' plug-in icon: an wall plug with an electrical cord. That typically happens when you run out of memory and freeing some up will 'fix' it.

Completely agree with Vincent. You need to create simple target tables and test the scenarios you want to capture and see what happens. It's quite odd what it will and won't even report, let alone capture via a reject link. Glad to hear it is 'mostly' fixed in coming connector.

You tried with with a single address and... did it work that way? Trying to understand if you can't get it to work at all or if the issue is only with multiple email addresses.

Short answer is no, at least not by itself. The actual scheduled job must be either manually reset or monitored and reset by another process. Which could be scheduled to check 10 minutes after the other runs.