DSXchange

How about sharing with the rest of us what the actual problem was and how you solved it?
After all, that's one of the main purposes of the "Exchange" - to exchange ideas, techniques and solutions to make all our lives easier.

Just deleting the entries from UV.ACCOUNT, while necessary, is not sufficient. You also have to correct the SQL system tables for DataStage. Making an error with either step can be catastrophic, so make sure you have a system backup first. To effect repairs to the "SQL Catalog", which is how DataSta...

You can certainly do this. There are many techniques, you can search for them on the Forum.
Then again, you may not need to. If the target database supports serial data type, or sequences, then you can have the surrogate keys generated when inserting rows into the dimension tables.

Erk. Can you connect using the Administrator client? There are serious problems with the projects. My guess would be that they've been (re)moved from their previous locations, or backed up and restored (part of a disaster recovery exercise) without due care. Can you access the server via telnet, cha...

Try using @NULL rather than @Null. Some versions of the compiler are finicky about the casing of system variable names. Apart from that, the expressions look OK, at least in terms of matching the left and right parentheses, which is what the compiler is complaining about. It might help if you could ...

chulett wrote:Yes, it is. Thought for a minute about using "Get Ax. Kill Troll." to continue the theme, but...

"Eat mushrooms" sometimes works.

If your hashed files have 32-bit internal addressing (the default) they can only be up to 2GB in size. If your hashed files have 64-bit internal addressing they can be larger than 2GB. On Solaris the ulimit -f command will report the maximum size of an operating system file, however "unlimited" is m...

Do you import the metadata from the UV table or hashed file to use in the UV stage or hashed file stage respectively, and load the imported metadata into these stages? This is the recommended best practice for ensuring that the metadata in your job designs coincides accurately with those in the data...

Welcome to the DSXChange! :D

Adjust the metadata in the hashed file to what DataStage is saying it expects.
This will prevent the warning message from occurring.

There isn't a lot of "code" as such, and what there is is DataStage BASIC. Do your interlocutors understand DataStage BASIC? What I prefer to do is to load up the graphical interface with lots of annotations (they're cost free at execution time) explaining absolutely everything that's going on. For ...

uvbackup and uvrestore They don't appear anywhere in the DataStage manuals. Next time you're at the "UniVerse" prompt (preferably in a telnet session) execute the following commands (case sensitive): HELP uvbackup HELP uvrestore It's been there at every release since 1.0, and is still there at 7.0.1...

Telling the Aggregator stage on its input link that the incoming data are sorted - for that is actually what you are doing - is believed. If you lie to the Aggregator stage - your data are not sorted even though you say they are - you will be punished by the Aggregator stage aborting. Are your input...

Yes, well done (for all kinds of reasons).
Almost time to get out of the twisty little maze?

Whether or not you can roll them back depends on your commit strategy. If you're using auto-commit, for example, the answer is clearly no - each row that has been inserted has also been committed. In this case you need a strategy for undoing the inserts. On the other hand, if you've specified that t...

There's a manual in the DataStage documentation set on hashed file caching (dsdskche.pdf) which explains all.