DSXchange

I agree. Being anal, the function only 'keeps' the delimiter if you tell it to return multiple delimited substrings and then only between the instances. So 'using' would have been more accurate. And to continue the theme: So the field operator does use the . as delimiter for extracting from a decima...

ssnegi wrote:Yes field function can be used to extract from a decimal keeping the decimal point as the delimiter.

Interesting... and all these years I thought the Field() function only worked on delimited strings.

Check the documentation for that IsValid function. You would use a type of "timestamp" for the first two and "time" for the second two. And then the format string you would craft from the options noted here based on what your incoming string looks like. Have you tried using it ye...

OK... that was the only scenario that made sense to me when one is dropping and recreating a table each run in case it changed. Otherwise you have to update the metadata and the job then redeploy it anyway, we would be including the full DDL with the job migration package. Table drops lose all of th...

I believe they are trying to import metadata from that DDL.

(see Additional Info)

Can we get the actual error, please? And a question would have been nice, too.

Note that I removed an enormous quantity of column names in your example, don't see them adding any value and they made the display... awkward. I've saved them off if they become relevant...

It is more forgiving of things like that when configured properly. A Server Shared Container in your PX job could be leveraged as well to run just that stage.

So... any chance you can post this new design? I'm curious how different it might be from what I suggested.

So, exactly the situation I described and something you cannot do. My answer still stands, I'm afraid. And ssnegi, that's not a proper looping design for that, at least not in my book. The loop should only encompass the first job and loop while it fails. The iteration it succeeds it should exit the ...

You could also look into using a Sort stage set to whatever the "Don't sort, already sorted" option is actually called in order to preserve the order. Or perhaps a stable sort. Or using that APT variable that shuts off sort insertions... Or just use a Server job if nothing about this reall...

You can't "loop back again to the test job activity", if that means what I think it does. If that's just a hard link from some point back to the beginning then your "first" stage is no longer a starting point as that would be a stage with only links coming from it and none going ...

kaps wrote:Looks like we just have to live with the option of having to drop the table manually whenever we make changes to the table.

So... this is an RCP enabled job?

Exactly. The only way to ensure that no dataset is created for zero records is to not run the dataset population job. Likewise, to ensure the table is not "recreated" for nothing you cannot run the job with that table as its target from an empty source. All of that happens before any data ...

As noted, that APT variable is DB2 specific.

Wow... ok.