DSXchange

It will only show up there if you've defined it as a 'Before/After' subroutine.

Right, NULL is never equal to anything, including another NULL. You need to check to see if something 'is null' or 'is not null' using the appropriate functions depending on where the check is being made.

You haven't mentioned your database, but what about doing something like this, which is Oracle syntax: select NVL(MAX(col1),0) from table A null result would be substituted with a zero (or whatever would be more appropriate) and then you could make the source column non-nullable. Yes...

It works the same for PX AFAIK. Those, however, are job macros who's formats may not be exactly what you are looking for. You can always generate the date in your desired format and specifically pass it into the job in question as a job parameter. Those would be used in the same manner. Or create a ...

I stand by my solution and claim that no "other" solution is required to meet the need described in pat_raman2000's two posts. Of course. However, like most of the time, there's more than one way to skin this cat. All I was attempting to point out was that (in my opinion) the focus on just warnings...

Your suggested solution does not seem to take of Job warning and corresponding Job Sequence abort - Observation from an experiment. Wait... which 'suggested solution'? Both are equally valid, the first as long as you understand my posted caveat re: warnings while the second stands on its own regard...

Ok, here's where I get to eat some crow, as they say. Nothing like sitting back, pondering for a moment and building tests jobs before posting absolutes. [sigh] I didn't miss anything, Ram, I based everything I posted off of my 'standard' Sequence job design I've been using for a number of years. Wh...

Which means you should scroll up to your first post and mark the topic as 'Resolved'.

Good Lord. Re-read my post, which is a simple and complete solution. You've made it unnecessarily complicated, given some incomplete information and need to understand that a Sequence must abort to be restartable. ps. The Sequencer is needed unless you really want to hang all of that extra crap off ...

Sorry, but that isn't true. Enable automatic handling and then include only an OK trigger to the next job - it will abort the Sequence for anything else, including warnings. Job3 will need an 'OK' trigger as well for everything to work properly when it has a problem. Add a sequencer to the job and l...

Use normal triggers, no need for anything custom here and you are just confusing the automatic error handling. For 'Finished' use 'OK - (Conditional)'. For 'Finished (see log)' use 'Warning - (Conditional)' For 'Aborted' use 'Failed - (Conditional)' For anything not covered by the stage's current t...

dstage443 wrote:also how can i set default values ....most of the fields in the tables should be set to default ....

True database default values are achieved by not including the columns in your job.

First off, understand that a while a dblink does allow you to 'join' tables in disparate instances, the data from the remote database still needs to be sucked over into the originating database, built there and then joined to your tables. So, while it can be a simple solution to the problem, it's no...

Please do a better job of choosing Subjects for your posts, it should be specific to your question or problem. At least you didn't just say "Hi" like we've seen in the past. As to your question, why would you want to use ODBC over a native stage for any database? To me, ODBC is the 'stage of last re...

One supports a single interface / API while the other supports several.