DSXchange

Naming conventions? Ha!

Where Used was (and I assume still is) a toolbar icon that becomes active when an object is selected. It looks like a flask from a chemistry set from what I recall. Might even be a right-click option now for all I know. Really shouldn't be all that hard to find.

Have you opened up a support case for this?

actually i cannot install the dukes code in my client network. I find it interesting that while you can't install Kim's code, you'd happily take mine. :? Go through the "online" help Index for the functions that start with "DSGet", they are the ones you'd need to leverage to ext...

You posted in the Server forum yet marked the Job Type as Parallel... which is it?

Sorry but there's no code in my post. And you should be able to see enough to know you don't start with the code... that comes last.

If you just want code then follow Arnd's link to Kim's site and download the ETLStats package from his Tips and Tricks section, it is chocked full of it.

Also note there is far more than a single "routine" needed to do this. And you need to plan out your methodology before you start any coding. For example, how will you be interfacing this log gathering to your jobs? Meaning, will you add something "after job" to every job [shudde...

kiran0435 wrote:I want to run the job on 4 nodes without adding apt_config_file parameter to job.

You can't unless you make your default config a four-node config... which would then affect everything. Add the parameter. It is part of a set of APT variables that (IMHO) should be in every Parallel job.

There's a macro for the Invocation ID - something like DSJobInvocationID off the top of my head, check the docs to get the proper name. Not sure I'm following but if you want to use an Invocation ID in an output filename, that macro will fulfill that requirement.

+1

Please clarify for us what the datatype of the column is in both the target table and the job.

And "old" means in an upgraded job from before looping was added I assume, yes?

And also keep your logs small by minimizing the messages that actually get logged by aggressively eliminating all that you can. I'm curious what other kinds of "R/W" you are seeing there? Anything? Hopefully you are not persisting any user data there...

Funny, exactly what I was thinking. And the answer is, of course... Ernie.

As Ray noted - best practice is to only use "user-defined" SQL when you have no other choice, otherwise let the stage generate the SQL. A "normal" delete will work just fine for this.