DSXchange

Sadly, no - no pictures, the camera stayed at home. Besides, this wasn't exactly a seedy bunch so probably not all that many opportunities for embarrassment would have been to be had. The conference was decent and as Vincent noted, quite large. Much walking was had by all and sometimes the next sess...

Did you try searching for that message in the forums? Been discussed here a time or three...

Only 608 unread messages when I got home. Probably half of them from Ray, I'd wager.

But I am not clear about, why the last row or the first row was passed when bind variable is not used. That's just The Way It Works. A lookup can only return a single row unless you are using ODBC or a UV stage for the lookup, so you only get the first or the last. Oracle gives you the last row as ...

Welcome! :D Some general rules for lookup queries: * You always need to select as many column as defined in the stage, in the same order * Key fields are used in the where clause and require values from the input link * Better to use a hashed file rather than a database stage for lookups * Best to l...

Said pretty much the same Arnd did. Investigate the Convert function, use multiple Char() functions cat'd together to build the list of characters to change.

Here's a "trick" so that you can use the "Insert Job Parameter" helper. Right-click on the DRS stage and select Grid Style which is the old way you worked with the stages. Switch to the Properties tab and then use the Insert Job Parameter tool to populate your connection information. See if that he...

If just the length is the problem then you are probably out of luck, having passed some internal size limit such that the sql ends up getting truncated.

Have you opened a case with your support provider?

You can't. It must be a Job Parameter passed in from another source, like another job or routine. A Sequence job could easily do the trick, read the file to get the parameter value and then pass it to your processing job.

But it also would not have generated the SQL with a parameter marker in the where clause.

Please remove your duplicate post - edit it, check off the Delete option and then Submit.

You need to 'source' your dsenv file first, then run the job:

That makes no sense. The log always just shows the sql statement once with the bind variables in place, not repeated over and over with each row's values subsituted in.

That statement looks equivalent to saying 'where 1=1' and would delete the entire contents of your table.

SEEK with the correct argument will get you to the end of the file in a BASIC routine. Then you could back up from there. Or "tail -1" in UNIX or MKS Toolkit.

Yes, with the exact same answer as previously given.