DSXchange

Huh. No, there isn't. So, it shows no PIDs even if you switch either side to 'Show All? Is there anything different about this environment?

Are you sure this is good advice? Up the MAXKEY value to 20000 ?

Usually I would have expected to see dire warnings about the consequences / side effects of this, or questions on why someone would really need a hashed key that large. [shrug] Whatever.

ps. It would be simpler if you learned about and starting using the 'user status' area in jobs. No intermediate file needed, no funky trigger handling, just a job that stashes something there and then $UserStatus can be used directly. Search the forums for either "user status" or "USERSTATUS" as thi...

Your job flow ascii art is hard to grok. Short answer - try this in your trigger: Head.$ReturnValue<1> < 34 -or- Convert(@FM,'',Head.$ReturnValue) < 34 As for your message, it means exactly what it says. Flow went into the Sequencer but nothing ever came out the other side. This typically oc...

Nothing. Just use them.

We know, Ernie. Just still noting that it requires IBM to bring that particular gun to bear on your target, it's not something you can just request and get your hands on.

There's nothing required to make this work if both are just doing lookups. You've got a problem with the job itself that got back 0 rows.

Or there's always what Ken posted. Don't know why, but I always forget about 'compare' for some reason. D'oh!

Haven't seen that problem before, but if that's really the problem you can try one of the 'string' functions noted in the BASIC manual pdf. Specifically, the SCMP function: Use the SCMP function to compare two string numbers and return one of the following three numbers: -1 (less than), 0 &#...

Again - do you really need to load the entire record into the work table for this join? If yes then carry on, just wanted to make sure. As to your problem, I'm not understanding your issue so can't give much advice - other than to ask you to try to explain it again. Perhaps you could post the table ...

Oh Gawd, not a LONG. Use a CLOB instead, unless your version of Oracle is so old it doesn't support them?

Yes, you do. And then have someone severely thrashed.

Whomever was transferring the file would need to do that, post transfer. You can't, unless you first check to ensure the file is completely transferred, and if you do that we're back where we started.

You "avoid the cartesian product" by joining on the proper keys. Why in the world can you not simply do that here? If you "can't do that" for some reason, I really don't see how you can avoid the cartesian-then-filter approach. However, you could arrange for all of that to happen in the source sql, ...