DSXchange

The Administrator is the 'where' and if it is 'pathed' - i.e. lives in a directory rather than an account - you would need to have created the pointer manually. Sorry, don't have the time right now to explain that all properly.

A 'continuous' WISD job would do this automatically. Otherwise, you'll need a 'wrapper', something to monitor it, check to see if the failure was db related, check the db, relaunch the job when it is back up, etc etc.

As long as the hashed file has a VOC pointer established, i.e. it is account based or you've created one for a pathed hashed file - then you can issue a COUNT <PointerName> command to get the number.

Well, that was odd. Seemed like this was marked as Resolved while I was in the process of submitting my post. Hope we agree on the answer.

Sure, that's what the "Trigger Column" option does - spawns a new file every time the value in that column changes. You'd need to ensure it changed every row. And note that it does not need to be a field you actually output into the XML itself.

Those are going to be database specific stages, typically tied to the interface they are named after. OCI = Oracle Call Interface, CLI is for Informix and any 'Load' stage is usually a bulk load of some kind.

No relationship. Nodes are a logical concept and do not represent number of CPUs, servers or anything of that ilk.

Answer Ernie's questions about your xml. Without the gory details, no-one can provide much more help. Five hours for that many records does seem too long for just file-to-file processing, unless there are a crapload of elements to parse.

Ernie, isn't this still an optional add-on one would need to buy if they wanted to leverage it? Perhaps no license was purchased.

Or use Version Control to automate the process!

Julio - not to be a 'noodge' but you are aware there's no need to quote the entire contents of every post you reply to, yes? There is a perfectly lovely Reply to topic button that starts you off with a clean slate.

Attention to details, please.

First, this is a Server job question so a PX solution doesn't really help. Secondly, the question was regarding a reference link to a transformer, which means using the stored procedure in a lookup, not as a target.

I would probably initially capture them to separate reject / error files and then add a post-processing job that builds the combined / finalized file and enforces your 'only from the first job' rule. Of course you'd need some kind of intelligent naming convention so they sort properly in order to fa...

Problem is I have no idea what "BCI Error:SQLSTATE=77,CODE=0" denotes. Perhaps it would help if you posted your driver entry details.

That or "correct" the file you're creating to not include the quote characters.