DSXchange

As long as you create a VOC record for it or even without one?

The answer really depends on what it does and when you need to call this - once? Several times? Once for each row of data through a job? (yes, people have allegedly 'needed' to do this) Hence the myriad suggestions.

Ahhh... reminds me of the Good Old Days when you had to Validate your dang jobs to create the hashed files.

FYI... you need to use an 'Account-based' hashed file to have this option, from what I recall.

Fixed your subject three times now. Please use meaningful and appropriate subjects in the future.

Done. Two times now.

DataStage installs the MKS Toolkit on Windows so you should in fact have UNIX-like capabilities and thus commands like "ls" can be used. Or just stick with "dir /b", either will display files alphabetically by default. That "/b" option gives you a "bare" listi...

san_dwh wrote:how to find out delemeter used and how many colomns are there?

Two basic ways:

1. As noted, use 'vi' to open it up and look at it. Or 'head -10' perhaps.
2. Ask whomever produced and/or sent the file to you.

The second way will be more important if the file has no 'header' record.

There's not really anything to explain. Oracle uses the tnsnames.ora file to know where the database lives that you are trying to connect to and how to connect to it. If you are unsure of the contents or what you'd need on your server, have a chat with your DBA as that's really a DBA task to do thin...

No, not required... and the configuration depends on the database but typically just involves pointing things in the right direction. For native stages like Oracle, that means the client software on the DataStage server and an updated config file (like tnsnames.ora) there as well.

You'll need to use the ODBC stage for that since it doesn't care if you don't bind columns into the sql. One link for commit and one for inserts. Add a rollback link if needed.

Things should be being passed fine, it would seem, so I'm assuming your issue is on the actual usage side. Since there's no final delimiter in your pathname, you'd need to include one when you actually assemble the parameters: #SrcDir#/#SrcFile# Or if you are doing this in your stage: #SrcDir##SrcFi...

That's not nearly enough information for anyone to be able to help. However, an exact search for "DSD.BCIPut call to SQLExecute failed" returns 98 matches, see if any of those other posts help.

You only need the quotes if there are spaces in any of the parameter values, so try again without any. And you still show the command without the proper whitespace between all the bits.

As you noted, the first is a simple lookup that you need to ensure continues after a lookup failure. Downstream of that, if the first lookup failed and that value is null, do a second ranged lookup for your 'between' value.

Have you tried to implement it yet? Do you have any specific questions?