DSXchange

Exactly.

I don't see you having any choice other than to "identify the deletes" and doing them beforehand, even if it is "costly". Join the source and target then runs the deletes, afterwards you can insert in peace.

That would be a question for the original poster and unfortunately they haven't posted here for almost 4 years. If you are having a similar issue, suggest you start a new post with your details.

Yes, truncate before loading but you can see from the proposed design that it would be run as a 'stand alone' job after the load failed to do one thing - truncate the table. So I figured before there would be ok and then the SQL could be something you know would have no impact, like perhaps a delete...

Without the space between the dash and 'param' of course.

From the Oracle Connector documentation: 3. To truncate a table at runtime, perform these steps: a. Set Table action to Truncate. b. Use one of these methods to specify the TRUNCATE TABLE statement: * Set Generate truncate table statement at runtime to Yes, and enter the name of the table to truncat...

I suspected that might be the case but was hoping they could be more precise in their requirements statement.

What columns are you referring to? I don't mean their names but where they live, what table(s) they are associated with.

How exactly are you verifying this? What does the insert SQL in the stage look like, does it include a TO_DATE function for this field?

Declare the RATE_DATE column with a data type of Timestamp in the job.

Start a new post with the details of your error, please.

Basically, you need to decide what needs to happen when a 'failure' is detected. Do you pass back something as the 'Ans'wer that will indicate a problem that is then handled by the caller or will you abort the routine itself?

1. Export from 8.1
2. Import into 9.1

Are you sticking with this configuration? Doing all of your development in an older version and then running the new version only in Production?

I'd involve your official support provider, if you haven't gone down that path already - see what words of wisdom they have on the subject.

Not sure I consider that a 'workaround' but rather proper usage. :wink: :wink: Specifically for #1, put the macro in the Initial Value of the stage variable and then leave its derivation empty. It will only be evaluated once (the performance hit) when the job starts and then simply used for every ro...