DSXchange

Well, looks like we're at that awkward moment where it becomes too hard to figure out what's going on without seeing the job itself. My email address is in my profile, if you want to export it and email the .dsx to me I'd be glad to take a look at it. Otherwise, if someone else wants to step up and ...

I'm pretty sure about it... however, it's not anything I've ever tested or would swear my life on. Hopefully, someone knows for sure.

You could switch to flat files named after the instance id or perhaps a hash stage with records keyed by instance id, I would think.

Hmm... actually, I now see you mentioned a 'Composite' date field, which is the only key we should be using in the query. So your where clause should actually look like either one of these two: WHERE TIMES.PERIOD_SET_NAME = 'MTHLY' and TIMES.START_DATE <= TO_DATE(':1','YYYY-MM-DD HH24:MI:SS')...

When you get right down to it, it is still just one job that you can run multiple times in parallel. One job = one USERSTATUS area and since it is basically a hash, last one in wins.

Find another methodology to pass whatever information you are passing via USERSTATUS right now.

As I said, you'll need to use 'TO_DATE' around your key values. Assuming your fields are defined as Timestamps in DataStage, try: SELECT TO_CHAR(TIMES.START_DATE,'YYYY-MM-DD HH24:MI:SS'), TO_CHAR(TIMES.END_DATE,'YYYY-MM-DD HH24:MI:SS'), TIMES.QUARTER_NUM, TIMES.PERIOD_YEAR, TIMES.PER...

This is an interesting challenge because DataStage automatically prepends the schema name to the table name in the metadata definition. It only does this when you tell it to. If you uncheck the 'Fully qualify' option when importing the metadata, it won't do that. At least that's the way it works fo...

No, not the error - your actual custom SQL. The version you are running right now.

Post your custom query. Don't type it in, use cut-and-paste, and wrap it with the "code" tags so that it looks like mine when you 'Preview' it. Then, we'll see what we can see...

If you look at any of the SQL that the OCI stage generates, you'll see it doesn't use question marks as parameter markers, they are specifically numbered. Since you are using Custom SQL, it is also your responsibility to ensure that the columns you select match - in order and number - the column you...

Welcome aboard! You just need to switch the OCI stage to User Defined SQL and then you can code in your 'between' clause. Make sure to model it after a 'normal' lookup - mark your Startdate and Enddate fields as key fields, make sure all columns have parameter markers, etc, etc - and you should be f...

Hmmm... another reason to not use the Fully Generated option. I personally stick with Column Generated.

My suspicion is that this code is in the Job Control tab of a Server Job, not out in some separate job control - or at least that is what I was attempting to ascertain. The other solution is to compute the prior period inside the actual Oracle query. I've just done exactly that, establishing a query...

Tell us exactly what you mean when you say:

In the Job Control of the job I have a sentence

You can basically do what you are trying to do, I suspect you are trying to do it in the wrong place.

OCI expects you to be using a datatype of Timestamp when dealing with DATE fields, in "YYYY-MM-DD HH24:MI:SS" format. Read the plugin documentation for the stage.

As noted, ideally your jobs can handle anything thrown at them and will never log any warnings. However, when things do get logged, you decide what happens in your Production environment by the way you setup your jobs and your error checking. If you mark a link as a Reject Link (which can be done wi...