DSXchange

So... is the requirement based on there being at least one period in the string? If so, a combination of Index() and Field() should do the trick.

A couple of points... We have chosen the 'auto' partition in join stage and the env variable 'APT_NO_SRT_INSERTION' is set False This is the same as not even mentioning the variable as that is its default value. Add them to give you the ability / option to override them later but don't think simply ...

This 'date' field, what actual data type are we talking about? The current answer is fine if you are talking about a string but it's not correct for an actual 'date date'.

1. Pretty sure that happened before 7.5.1 so probably a non-issue. Short answer, yes - compatible. 2. As noted, exports and backups are always good to have. Known where all your 'extra' bits are - scripts, reference files, etc - and what 'optional' stages you have installed so they are there on the ...

From what I recall, this is driven by the syntax you use to 'attach' to the job in question, create the handle. The 'ERRFATAL' option or some such? Can't look it up at the moment.

Then make known that need in your post, not here. And when you do, let us know why the suggestion already made there isn't working for you.

Well... the way that was posted in your own thread on the subject comes to mind.

The answer depends on many variables so there is no blanket 'best' here. The first may very well be the best in your case, but there isn't any way for us to know. And yes, if you go for that first option, since the job will have no idea you've done so you will more than likely need to add specific S...

The question mark at the end should let you know I was making an (hopefully educated) guess. And that only because I've seen all kinds of strange things happen when processes run out of space. It's not always a nice clean "device full" or "out of space" message, many times it can...

For Server, you don't really need the TO_NUMBER conversion. Try keeping just the TO_CHAR in your source SQL and simply move the result to the numeric field in your job.

Recompile them.

And if that doesn't help all that much, come back and ask again.

A little sparse on the details. Is this Oracle? Is your YEAR_MONTH column defined as a NUMBER in the table, i.e. unbounded with no precision?

Create a work table, load the list of values there, join with your table. ... Could you please elaborate the logic. Which part is unclear? Your particular work table would have a single column in it for DEPT_NM which you would load with whatever values needed to be used to constrain the current run...

Seems like it's time to involve your official support provider.