DSXchange

That doesn't exactly look like a common error. In your shoes I would take that to my official support provider, ask them for help with it.

Do you know the maximum number of delimited values? If so, code for that.

oracledba wrote:simply only include this

StringToTimestamp(lnk_CONV.TS4)

the extra fitting is causing the error.

Sorry but that's just not correct and will generate syntax errors as well.

One way would be to turn on the "Automatically handle activities that fail" option as it considers a non-zero return to be a failure. Or you could run your failure check trigger to a Terminator stage.

Fix your format in the transformer StringToTimestamp() function call. Nothing else to do for that particular issue.

The Sequence must abort for the checkpoints to work. When the status shows "Aborted (Restartable)" then you can either simply Run it to pick up where it left off or Reset / Compile the sequence job if you want it to start over from the beginning.

LOL... we had enough problems getting it changed to say 30,000.

Two Field() functions could pull each piece out, first delimited by pipe and then the result delimited by comma. If you are on 8.5 or higher, transformer looping can be used to iterate through the fields based on a count of the pipes.

Exactly. They allow no duplicates and destructive overwrite means "last one in wins".

As the error notes, your format is invalid. From the docs:

For a timestamp, the format is %yyyy-%mm-%dd %hh:%nn:%ss. If extended to include microseconds, the format is %yyyy-%mm-%dd %hh:%nn:%ss.x, where x gives the number of decimal places seconds is given to.

So you completely ignored my advice... interesting. What happens when your two digits come in as "97"?

Oh, that.

Open up the Parallel Job Developer's Guide pdf and search for year_cutoff which specifies the century pivot for two digit years. It defaults to 1900 which is why you see the behaviour you are seeing but you can override it in the format string.

Since you didn't supply a time, then either "00:00:00" or "12:00AM" should be expected. What it looks like on output is all about your SELECT statement and the TO_CHAR() format string you (or your tool) is using. There's nothing wrong with what you've stored in the table.

You really should have it stored somewhere, failing that you could select CURRVAL rather than NEXTVAL from your sequence.