DSXchange

It wasn't a 'work around', it was a diagnostic technique. Did you actually enable server side tracing and inspect the trace file?

Regardless, sounds to me like it's time for you to contact your official Support provider and get them involved in your issue.

Wasim was not using a hashed file, the only known mechanism for which the NOTFOUND link variable is reliable. Agreed, the link variables are only reliable for a hashed file lookup. For any other stage, fall back on the original mechanism of checking for a null Key field post lookup. However, I base...

I'm always leery of a "dot oh" release of any product, especially when that release is a major upgrade from the previous release as in this case.

Old style. You could also use an Input Link Variable boolean:

Why not ask the people that suggested it to you?

I would think you'd need to ping the vendor for something like this, open a Support case. Or perhaps wait and see if Ernie will swoop down and help out. I'm curious... a 257K XSD file? And that's "your smallest"? I've never seen one more than 1/10th that size, even for our most complex. It may be we...

You would need to drop all mention of the 'serial' field from the link. Make sure you Annotate this so others know what is going on.

Difficult? Impossible.

EssEss05 wrote:I have tried with surrogate key generator stage but its not possible to specify the highest value of last run.

Not true. Read the documentation a little more carefully.

There's a difference between selecting a 'max id' from a table (which the OP shows as 'select nextval') and the use of 'dot nextval' in user-defined sql. Unless it works totally differently from its counterpart in Oracle, there are no single threaded issues with the latter.

Technically, 'shell scripts' are a UNIX thing. Since you are running a Windows based DataStage server, you'll need to write a 'batch file' instead. Well, unless you've got something like the MKS Toolkit installed which brings UNIX functionality to Windows. My batch file writing days are long behind ...

Unfortunately, OCI won't ever be so helpful as to actually tell you precisely what the problem is. Just that you've got one. As you've noted from previous posts, you've got a mismatch between the number of columns declared in the stage and the number of parameter markers used in the sql. This could ...

Note that exactly how this all works under the covers is not documented, so all we have is anecdotal evidence. From my experience, it seems the only check is against the configured limit, not what memory you may or may not actually have available at that moment. Assuming you haven't enabled 'System ...

DON'T USE THE FTP STAGE!

As noted, you'd need to write a custom routine if you really felt the need to convert this into a 'case' statement. You would then reference the routine in your derivation.