DSXchange

Maybe the answer lies in tnsnames.ora. Your Oracle DBA should be able to advise you on configuring the Oracle client (that is, DataStage), since you're only required to make this change because of the service name change.

(I'm a little surprised that you don't need to change sqlnet.ora.)

That's too simplistic to my mind. "Validation" will (should) tell you which one is wrong.

Use the format.conv (also known as fnuxi ) or uvbackup command to export the hashed files; this will also move their VOC entries. When restoring, use format.conv or fnuxi or uvrestore respectively. The format.conv and fnuxi commands have -export and -import options. You can find details for all of t...

I confirm what Ernie said. I recently had this exact scenario.

Note also that reports themselves are not imported into the repository; what the bridge retrieves is the report definition - it is possible, for example, to build a Cognos role that does not permit retrieval of data at all, but which can be used in conjunction with the bridge to retrieve report, que...

Check permissions in the DataStage project. Check that the disk on which the project directory resides is not full or a quota there is not exceeded. Check that you have write permission to the VOC in the project. Learn some troubleshooting skills.

If you can't find it under the ASBNode bath, look under the ASBNode path!


After his gig in Vegas, looks like Paul is taking the comedian thing seriously.

If it's in a database the data type, precision and scale will be correct ipso facto.

Otherwise (reading as strings) create a BuildOp.

What is happening in your job that requires or generates cookies? There's something you're not telling us.

What have you designed/tried and how did what you tried fail to meet your expectations? Are you using a version with looping available in the Transformer stage?

Vincent obviously didn't max out his IOD schedule attending presentations, usability sandbox sessions and hands-on labs like I did.

There's also a Ctrl-Z in there, fairly early. This is the DOS end-of-file mark. You shouldn't be reading past this character (on Windows) but, since you're on UNIX where Ctrl-Z has no particular meaning, the operating system is merrily reading bytes until it encounters a UNIX end-of-file character (...

My guess is that the problem is the "#" character in the password. Check the documentation (or Information Center) about handling special characters in passwords.

Depending on the database, there should be a function called something like RAWTOHEX. Use that in a user-defined SELECT statement.

Well done. That would have been the advice I'd have given had I logged in sooner.