DSXchange

Not sure why you're surprised. You've done something in Oracle that isn't really recommended - used a reserved word for a column name. Now it will take special handling to reference it. Not all the time, mind you, but enough to cause problems like this. Try naming a column 'SYSDATE' sometime. You ne...

Sorry I wasn't able to help more. The fact that you have a working 7.5 server with an ongoing project in it pretty much throws all of my advice out the window. Which is ok, may give someone some ideas later if they stumble across the thread. Since you've imported before, I'd guess your export was co...

Have you checked to see if the RPC Daemon is running or not? Your SA may have gotten a little over-zealous and killed one too many things:


If this doesn't show a process, then suggest you stop the DataStage server, wait a few moments, and then restart it.

No, not really. Some questions for you... Is there any difference between the two UNIX environments? Did you verify the correct operation of the initial 7.5 server install before importing your 7.0 jobs? Was the 7.5 server install done as root or dsadm? Were there any errors during the export you ar...

Yah, deadlocks of that nature are difficult if not darn near impossible to troubleshoot. Something to consider - drop your indexes before job and then rebuild them after all inserts are complete. Not sure how feasible it might be to do that given your volumes, but it would eliminate another possible...

Probably related to the fact that the default precision in DataStage is 15. Check this post for a methodology to determine your current setting and change it if desired. It will also introduce you to the 'string math' functions. One or the other should fix your problem.

I also notice that when a table load has failed then sometimes there are no records in the table. And I would have expected/guess that some rows multiple of 10,000 rows should be there (rows per transaction * parameter array size). I am not sure how often the ODBC stage commits. Just an FYI - 'Rows...

Heard through the grapevine that one of the problems with the site today might have been a failing hard drive on a new server... and it sure looks like it may have actually failed. The site seems to have been restored from backup and we've been time-warped ("It's just a jump to the left...") back to...

Sounds like you are not doing a binary transfer. Make sure you get your transfer program to do a binary (rather than an ascii) transfer and you should be ok.

What it means is you have to specifically point to the 32bit libraries in dsenv:


If you need to include them both, make sure the 32bit library is mentioned first in your shared library path.

ArndW wrote:(we are just doing this to boost our points in this forum, so that we can surpass Ray and get a free <something> )

You guys are... well on your way.

For starters, there is this post where someone just asked the exact same question.

If you are really concerned, do you have anything like a 'test' server you could perform the upgrade on to get some warm-fuzzies with the process and the outcome?

Not that I'm aware of, but that's not to say there weren't any. Best place to look would be in the readme for the 7.0 release. It will list a number of changes and fixes in the current release, even a list of known problems. Your issue could be something that shouldn't have worked the way it was wor...

From what I understand, the correct answer is 'N'. It means you've launched the command from a non-project directory. Unless you are actually trying to create a new UV account...

From Ascential's eServices website. Under Software Updates / Downloads.