DSXchange

I would feel confident in saying that if your platform supports concurrent licensing for the compiler, you'd be fine as you noted. Unless Ray notes otherwise, of course.

You'll need to post more than that as that's not any kind of an error. Is there something more descriptive that you received or that was listed around that one?

Karthik.M wrote:Thanks for mentioning the "View Data" bug.

Why the thanks? I might as well say "Thanks for running around and resurrecting old posts".

(serious question btw)

hi Harikumar, you really should put together better posts than this. Rather than "hi" you might have simply put "Surrogate key" as your subject and then a more fleshed out version of your questions in the post itself. Something more like: What is the use of a surrogate key? When...

A surrogate key is a unique primary key that is not derived from the data that it represents, therefore changes to the data will not change the primary key. In a star schema database, surrogate keys are used to join a fact table to a dimension table. Straight out of the documentation for the stage....

I imagine they've solved this problem by now.

Close.

cd $DSHOME
. ./dsenv
./bin/uvsh
LOGTO <Project>

What do you plan on doing once you get there?

FYI, sounds like you may already know this but search here for the SETFILE command, which is used to create the VOC entries you (may) need.

Which I did mention, just without the "rather than" part. Thanks.

You can validate the jobs and then copy over the hashed files or copy them and then create the VOC manually. Your choice on the manual step but there will be one.

And just to be anal, there's no "conversion" required. As noted, it's a simple migration possibly complicated if they are account-based rather than pathed hashed files.

Well... pretty standard stuff. Any command that writes its output to 'the screen' is writing to stdout. That output stream is what the stage consumes when the filter option is enabled.

Anything that outputs to 'standard out'.

In the 8.x release? I'm not so sure. And I thought the NAME field was only in DS_JOBS.

I wasn't thinking about how useful it could be in an ETL tool but rather outside of one...