DSXchange

What's your ultimate target?

What stage are you using?

We routinely ran our Server jobs with a warning limit of 1 as they should never have any warnings... as noted, that would be another option.

Not for warnings unless they exceed your runtime Warning Limit. Look for an option in the stage to 'treat warnings as fatal' if that's the behaviour you want.

emi1309 wrote:We are on version 5.3 and the upgrade is not planned...

Wow... seriously? Not sure how much help there will be for such an old version but we'll see!

It (nested sequence jobs) should be fine if done correctly and something I imagine is fairly common out there. I've certainly done my fair share. As noted, it's all about error propagation back up to the master sequence so your checkpointing works correctly.

It checks the file's size and fails the batch if the size is zero.

You would need to use a target stage that supported that, if so there will be a 'Transaction Handling' tab where the grouping actions would be defined.

It's not ok.

No, any equality check will be 'case sensitive'. If you need it to be case insensitive, apply UPPER or LOWER to both sides. I'm assuming this is resolved and marking it as such.

Qualifying the table name with the schema, connects us as an owner? No, they are two separate things. What I meant was, if you connect as the owner of the table you technically don't need to qualify the table name. Meaning, if you have a schema of TEST with a table called FRED, you can connect as T...

Depends on your environment and standards, I suppose. We never connect as a table owner but use a functional id that has the appropriate grants on all tables it needs to access. Which means all of our table names are 'fully qualified'. Your choice regarding the need to parameterize any of that. Anot...

Which means your connection user at runtime is not the schema / owner of that table.

The lookup is failing because the values don't match... but then I'm sure you know that. This is going to have to be pretty much all you figuring it out, what difference (however small) is causing the failure. However, clarify for us what are the data types involved on both sides of the lookup. For ...

Because this is where Server jobs are discussed regardless of "edition". Don't take the elderly forum names too literally.

Not possible with that design as those are all separate transactions. Use one connector with three input links and then look into the 'transaction grouping' option in the stage.