DSXchange

The quotes won't matter, it should work either way from what I recall. Did you try it? One thing you'll find is that DataStage loves to remove quotes from parameters so that could be an issue. However, there is an APT variable to stop that behavior if that's what you need to do - i.e. if you end up ...

As one solution, yes, since the only difference between a UNION and a UNION ALL is the former removes duplicates.

Verify that SET options are correct for use with indexed views and/or indexes on computed columns and/or filtered indexes and/or query notifications and/or XML data type methods and/or spatial index operations. And you're certain that they are "correct for use" as noted in the error? If s...

Don't "do" SQL Server but I would suggest you put the SET commands in the "Before SQL" area, perhaps without the GO, and leave just the select there as the source query to run. And there's no need for the second SET statements to undo everything.

Query the DS_AUDIT hashed file. If you are unfamiliar with it, an exact search here will turn up quite a number of conversations on the topic.

Remove duplicates stage afterwards.

Getting following error BillingUnitVw1: RDBMS code 3706: Syntax error: Invalid TimeStamp Literal. SQL statement: select lead_buid as value1, ' as value2, ' as value3, CHG_IND, 'BILLING_UNIT_VW1' AS TABLE_NAME, cast(cast(CHG_TS as date) as timestamp(0)) + (cast(CHG_TS as time(6)) - TIME '00:00:00' h...

That should work as well, I would think. It's all about getting the right one from the pairs you seem to have.

The fact that it is not bound into your SQL implies to me that you either didn't create a job parameter with that name or they're not spelled exactly the same - case matters btw!

Best to have that conversation with your DBA. Basically, a record is locked by another process, 'blocking' your process's ability to lock it before the update. I've seen it happen by something as simple as someone browsing the record in Toad and clicking on it in the Schema Brower data window which ...

For what it's worth, the only time I've ever had a need for a "varchar only schema" is when we were getting crap data from older systems via flat files. That allowed all of the data to actually load and then we could perform whatever validations were needed before cleaning / converting it ...

It's not about the datatype, at least not directly. It's about the fact that what is returned by that function is a dynamic array and the Field Mark delimiter at the end of the string is what makes it "not appropriate". Those other posts should have shown you how to remove them / it.

That error has been discussed here quite a bit. Do an exact search for "ParamValue/Limitvalue is not appropriate" for all of the discussions.

You can certainly use a single script if it is parameterized appropriately.

So make it a job parameter and bind it into the source SQL by surrounding it with hash signs:

select [columns] from edf_billing_unit where chg_ts < timestamp '#p_TIMESTAMP#'