DSXchange

Funny, but in thinking about these pearls of wisdom I wrote up earlier, I realized there really aren't two different paths to take, only one. And that is knowing the encoding of your source data and making sure the DataStage environment for the loading job reflects that. Both NLS_LANG and LC_CTYPE c...

Well, not really the Codepage God that Ray or Arnd are, but the next part of the exercise is this: What 'codepage' or character set was your data encoded with? This will tell you if a conversion needs to happen between the source and the target or if the data can be loaded directly. So, depending on...

So dosnt it metter what NLS_LANG value has been setup at the database level? Of course that matters. You need to find out what characterset your database is using, if it doesn't support what you are trying to load no amount of DataStage NLS magic will make it happen. Your session parameters are not...

It's not DataStage, it's the difference between running a secure transfer from the command line in an interactive mode versus 'unattended' or whatever the official term is. Did you generate an RSA key for the DataStage user / server and have it installed on the target server?

And? What happened? At the very least, you'll need to correct the #include path.

You need to use [code] tags to make your examples clear. Or people need to 'Reply with Quote' to see your original format as the forum software removes all extra whitespace otherwise. I don't see the point of this 'need', a single tab will work fine depending on what you are using to view the file. ...

So... UNIX not Windows as you marked the post?

Edit the uvodbc.config file in your Project directory, see if that helps.

Just use the number, don't include the word 'event' on the command line.

Hmmm... unless Windows is totally different, those aren't the ones to be editing. On UNIX there is a .odbc.ini in $DSEngine and a uvodbc.config in each Project.

Forget about 'jobid', it is not needed and only useful if you've assigned a job an 'alias/id' which not many peoples do, I'd wager. You missed the eventid which caused the syntax error. AFAIK, you need to get a list of event ids and then loop thru them getting the detail for each one. Now, I've neve...

Ah... now I know Ken is back.

As would Chuck Smith's 'list all files and tables' tool, especially if you stage up the results in a database table.

That should be - as already noted - that you are using logsum rather than logdetail... yes?

Bah, no uproar just our normal healthy discussions. I imagined that the first transformer would run in its entirety with create and delete command being issued first, then the second transformer would execute another create and delete and overwrite the first transformer's data. Nope, they would run ...

Doesn't really matter, one job had problems and the others didn't. As noted, for a "general network error" you need to check with your network administrator, not a DBA.