DSXchange

I've found a number of jobs where a Reject Link (not with the Reject Row checkbox marked) has a contraint of either "REJECTED" or "(REJECTED)". Does anyone use these and know how in the heck they are supposed to work? They don't seem to trap OCI rejects, hence my question.

Note that this is not LinkName.REJECTED which I can find in the documentation and have no problems with. This is the 'standalone' REJECTED keyword available from 'Link Variables / Outputs...' picker that does not seem to be associated with any particular link.

I'm also curious if there is any difference when used with parenthesis or without, as I see both scattered throughout the Project. I can't imagine there is, but then I'm not sure why someone would bother to wrap them around something like this, on occassion, unless it meant something.

What's an OCI reject? Is it when a Update statement fails to find a row to update? Noooo, it isn't.
Quoth the crappy documentation;
To catch rows which are rejected from a specific output link, set the Constraint field to linkname.REJECTED. This will be set whenever a row is rejected on the linkname link, whether because the row fails to match a constraint on that output link, or because a write opera tion on the target fails for that row. Note that such a reject link should occur after the output link from which it is defined to catch rejects.

When I want to know if a OCI link write operation failed, I ALWAYS use linkname.REJECTEDCODE. Accept no substitutes.
Naturally, this does not always succeed as in the case of TAF failover.

Like I said, I know about the rejects specifically tied to a linkname and I know it will work with all the goofy stuff that happens when you first start getting 'real' data that doesn't come close to looking like all of the test data you've seen before that. Duplicate Keys, Required Fields, Invalid Numbers... who-ha like that. Fine and Dandy.

I'd still like to know if anyone knows what in the heck "REJECTED" is supposed to accomplish.

Hi,
the only thing that comes to mind is perhaps a parameter or maybe a common variable set somehow.
other then that I see no real meaning.

IHTH,

Examine the code produced by any Transformer stage (in the RT_BPxx directory). This will answer your question.

For each iteration of the main loop, REJECTED is initialized to @TRUE.
If that row is processed on any output link, the value of REJECTED is changed to @FALSE.
When processing a [Rejects] link, it is the value of this variable that determines whether to process the row to that link.

Using that variable in the constraint expression has the same effect as marking the [Rejects] link with the check box, except that it does not trigger a warning message to be logged (which some people prefer).

Enclosing a variable name in parentheses turns it into an expression, making it proof against side effects (having its value changed in a called routine).

Thanks Ray. I was on my way home when I came to the same realization and smacked myself upside the head - why not not check the generated code? [thump]

The interesting thing to me is it only seems to handle 'logical' rejects. Actual 'physical' rejects, bounced back from a passive stage like OCI, don't seem to go down them. Does that sound like the correct behaviour to you? Is this little goodie actually documented anywhere? I couldn't find an mention of it.

Thanks for the clarification on the parens, my cohort will feel vindicated. Not that he remembered what it meant, just that it meant something special.

chulett wrote:The interesting thing to me is it only seems to handle 'logical' rejects. Actual 'physical' rejects, bounced back from a passive stage like OCI, don't seem to go down them. Does that sound like the correct behaviour to you? Is this little goodie actually documented anywhere? I couldn't find an mention of it.

I've not seen the REJECTED variable specifically documented, - for example there's nothing specifically about it on the "Link Variables" help topic.
It works OK with the ODBC stage in capturing rows rejected by the database, so I would guess that it's a function of whether the stage type is handling rejected rows "properly" and/or whether your parameter arrays size is 1 or some different value (so that the "correct" rejected row can be reliably identified).

Hi Ray,

REJECTED is not a Link Variable it is a SYSTEM VARIABLE.
It has been documented in "System Variables" help topic.

FYI i have pasted the same here:

REJECTED Can be used in the constraint expression of a Transformer stage of an output link. REJECTED is initially TRUE, but is set to FALSE whenever an output link is successfully written.


Anand

So it is! Right at the very end. But who scrolls right through to the end of a help topic?

Thanks for tracking that down for us.

Thanks as well. Interesting to me is the fact that it is chosen from the (...) in the editor from the list of Link Variables, not System Variables and doesn't have the leading @ you would expect. Oh, well... live and learn.

Hi
REJECTED Can be used in the constraint expression of a Transformer stage of an output link. REJECTED is initially TRUE, but is set to FALSE whenever an output link is successfully written.


?What does value 0 and 1 represent in above case?

Ketfos

From the online help for System Variables:

Help wrote:@FALSE The compiler replaces the value with 0.
@TRUE The compiler replaces the value with 1.

There are others well worth your time to check out.