DSXchange

What is the data type of your target table column? DATE? Unless you precisely match the NLS_DATE_FORMAT of your target, you need to use TO_DATE() in your SQL with a mask that matches your incoming timestamp's format.

D'oh! Who knew strings could be signed!

:!: And please stop quoting something every time you reply in a thread, do it when it makes sense, not all the time. Save me the trouble of cleaning them out from your posts. There's a perfectly lovely Reply to topic button at the bottom of the frame, use that rather than Reply with quote, unless of...

There's no ability to do a 'View Data' from that stage, as far as I know, not even sure that would make sense as it would have to run the merge to do so. So it doesn't surprise me if it is disabled. Having no DataStage access, there's nothing for me to test or play with, so I'm going to leave you to...

Interesting... there's only one other post which mentions "cannot have data in the SQL catalog" but I'm not sure how helpful it will be.

Not sure what to tell you since we can't see what exactly it is you are doing or typing. You need to put two full directory pathnames in the stage, one for the 'First File Directory Path' and one for the second, even if they are the same. Then just the filenames on the Output tab. The error sounds l...

What same way? Two files? Then I would guess you are not specifying the file names correctly.

As you saw, the Server Merge stage only supports flat file sources. So, yours are two separate databases? Can you load one set into a work table in the other db and then do the FOJ? Or why not simply land both sources to flat files and then use the Merge stage?

Sure, a Sequence job could use an Execute Command stage to issue the DOS "del" command, same can be done before/after job with ExecDOS or a routine could use DSExecute() to do that.

This should help.

Which is short for 'Unicode', btw.

The "u".

Hmmm... I believe that you'll need to leverage the VERIFY.SQL thingamajiggy. Do an exact search for it and take a peek thru the matched posts it brings up.

You can't select a column that doesn't exist, so you'll need to fix that in your source. For the reference, it sounds like you need to do a "range lookup" where your source date is between those two reference dates.

Until something official is added back into the product in a later release, then yes - any versioning becomes a manual process.