DSXchange

What part do you need help with? Did you do an exact search for "Possible range/precision limitation" to understand the warning?

Any 'fix' would still involve some level of code change, I would imagine. Sound like a question for your official support provider if no-one here chimes in with an alternative.

soportesis wrote:Yes, I need to run a job that is not into my project. Or is there an other way to do this into a sequence job?

No, that's how it needs to be done in that case.

Not sure but in your shoes I would try changing the bind variables to :1 and :2. You may also try that in conjunction with re-ordering the columns so the two key columns come first.

OK... that just means you want to use it. You need to ensure the actual jobmonapp daemon is running as well, which is what the suggested search would show you how to do.

No, not via a reject link... add a transformer after the sort stage and do the detection there.

The ODBC stage is the only stage that doesn't seem to care that all columns get bound into the sql, all others do. So you need to make sure all columns are bound by not mentioning the ID column in the stage and then using user-defined sql which uses all columns from the stage plus the 'identity' col...

nareshketepalli wrote:Hi can you tell me what is grid environment ?

http://en.wikipedia.org/wiki/Grid_computing

Bind variables.

If the auto-generated DML does the same thing it could be a bug. Post the actual delete statement you are using. How different was your SQL from what it generated?

Note that Ernie did not mention anything about 'Auto Check'... suggest you re-import the metadata as he suggested to see if that helps.

No, as far as I know it simply removes duplicates, hence the name. If you need to detect them and do different actions based on a row being a duplicate or not, I would assume a Sort stage with a Key Change column would be the appropriate approach. Then another stage could use that to determine each ...

Glad it now works! Keep in mind that that particular logic is not as efficient, nor considered best practice coding, largely due to calling Field() multiple times--as many as 15 or 16--per date column per record. You might consider using stage variables to store the result of Field(COLNAME," &...

battaliou wrote:I just noticed Ray's got more points than me.

You? All of us. Combined.

What environment variable did you find?