DSXchange

The names are a big clue. Select one and then look at the generated SQL. Select the other and check again. The answer should become pretty clear.

In my opinion, you improve the performance of any given job by not using either one of them. Use discrete insert and update links.

1) We really can't say. Try it and see.

2) Use hashed files for your lookups. That's what Server is all about, the proper leveraging of hashed files.

If you still aren't clear on this by now from the various threads on the topic here, I'd suggest you call your official Support provider. Have them see if they can explain it to you and help you set it up.

Still curious why in the world you would upgrade your development environment to a version you have no intention of upgrading production to?

You are looking for a sparse lookup. Or perhaps the Join stage as an alternative.

Which is fine and right where it belongs. Are the permissions correct such that your user can read them?

As I said, in this case going from A/T sizes of 1000/1000 to 100/200 won't change a dang thing if all you are sending to the stage are nine records. Your DBA still won't see any commits being done. Best you can do is set T Size to 1 and then commit on every key change. That would mean, based on the ...

What is your 'set of keys' - one record? If so, then futzing with the Array Size won't help at all if all DataStage see is 9 records. About all you could control from a Transaction Size standpoint would be if each set of records from any given 'key set' were committed per key change. That would take...

Um... Hello? McFly! What's wrong with the help you've gotten so far? If we're way off the mark, say so. And if so, you could start off by explaining why you "need" to get 2008-06-08 when you add "1 year" to 2007-06-09. I think most people would assume the date should be 2008-06-09. Explain the rule ...

In UNIX all you need to edit is the dsenv file. The others - .odbc.ini and uvodbc.config - are for (as their name implies) ODBC and not OCI. Other mechanisms control this on Windows. Have you installed the Oracle client on the same box as the DataStage server? Can you connect to a database with sql*...

Meagrees.

Ah yes... the Patent Pending Ray Wurlod Date Routines. Excellent stuff.

The record is discarded in the read stage, so the transform stage would never see it. Only if you tell it to discard them. That's why I prefaced my advice with "Let them come into the job". That referred back to the use of the Contains Terminators column option to bring them in as data rather than ...

Regardless of forum, I look at Job Type to respond. Hence the hashed file answer as well as the one for the question as asked.

In a Server job? Sort your data by SAL and then use your stage variables to do 'group change detection'. In other words, take the first occurance each time a SAL changes value. You'd need one to check current to previous and a second to hold the previous value - in that order. Or... just write them ...