DSXchange

Correct - but technically, it doesn't matter what order you do the two things in, as long as both are done before you try running the jobs again. Some people prefer changing the tables first, as this allows them to re-import the metadata and to test right away, but for a simply change you can manual...

Simply change your 'Update Action' on the 'Inputs/General' tab to 'Update existing rows only'. The stage will generate the SQL that you need.

Asked and Answered!

Check this post out where I had the same issue last October.

And if that's the case - I hope your Hash file wasn't in your Project! More troubles coming if so...

Not sure what you are asking... have you tried looking at or using one yet? You 'use' a Transform the same way you use anything else - type in it or pick it from the appropriate category of the little helper thing (forget the actual name) under the ellipsis (...) in the Derivation Editor. In this ca...

That's... odd. About the simplest derivation you can put in a job is @NULL, I can't imagine why that would cause all of those compile errors without seeing the actual job. I'd report this to Ascential Support and see if they can make heads or tails of it. As a suggestion, if you've got several colum...

Thomas, I'm assuming you are trying to connect to a remote Oracle 9i database, one that is not on the same server with DataStage. What you need installed on your DataStage server is (ideally) the same version of Oracle as is running remotely. You don't need to create any databases, just get it insta...

And for more information on functionality, read the .pdf manuals installed with your Client software. You should find a "Docs" directory there full of information, including manuals for the Oracle OCI8 and the two Oracle "Bulk" Load plugins. For older Client installs, you'll need to pull the Plugin ...

How many columns do you have defined in the link that is trying to run this SQL? One, I hope.

Try it without the trailing semi-colon for grins. The OCI stage doesn't like them, perhaps the ODBC stage is the same way.

How long do you wait before you decide something is wrong? Any chance your SQL statement may take a long time to 'build' and start spooling output? Big sorts or groups, perhaps? If so, that whole time your job will say Running but no rows will show as being processed - yet.

What user are you doing the Server install as? UNIX server installs have prerequisites, have you checked the README to see if there are any for a Windows server install?

Post the exact syntax for one of your derivations it is complaining about. I suspect you've got a simple syntax error and don't realize it. Apologies if this is old news, but to set something to null use "@NULL" instead of "(@Null)" which is how it looks like you are doing it from your compiler erro...

Yes, it is. But when you've got one you only want to set once and never change over the life of the job, a lot of people don't realize you can put the full derivation expression in the Initial Value field.

Double cool.

And I can't use the 'normal' SQL for a deletion only as it does not exist in the ODBC!! That's one of the (many) reasons I avoid ODBC if at all possible. The only reason I asked about the question marks was the fact that they aren't in the SQL you posted and said you were using. Just for grins, can...

Here is an example of the SQL I am trying to execute : DELETE FROM HMLIMSNRA.MILOCK1P WHERE (MLKEY = 2); An update would be UPDATE HMLIMSNRA.MILOCK1P set MLKEY=3 where MLLOCK=6; What are "2", "3" and "6" above? Column numbers? The ODBC Stage uses question marks as parameter markers, not column numb...