DSXchange

And you made these changes based on the reason in the linked article? Simple enough to test, it seems to me - set the values back and see if the error persists.

Did you try searching here for the text of the -14 message? It has been discussed here quite a bit.

Never run into anything like that and on the surface it doesn't make a lot of sense. I'd suggest getting your official support provider involved, see if perhaps it is something specific to your release of Linux.

Un-hijacked.

Keep in mind that a change at that level will affect all cached hashed files and effectively double the memory they will allocate when running (assuming you go 128 -> 256).

Is this "abc" sequence name used for the same target table in your two jobs or two different targets?

It would seem you are running the jobs with a "warning limit" of 1. How is it being executed?

Sounds like you have a synchronization / timing issue.

Never heard of it. Seems to me you should find a PowerShell support forum and ask there. Was it updated recently?

devesh_ssingh wrote:change of data type from Integer to Bigint

Would that not do it for you?

Question: If the source provided a record (delta) means, there is some changes in the existing record. In that case why should not we close the existing record based on the SK and insert the new record irrespective of what ever the changes it may / may not have? That's an Architectural question in ...

If it inserts rows, I suspect it should be setup as a "Target" rather than as "Transform". What is your job design?

That "Output" can be multiple lines and is returned in a dynamic array so you've got a Field Mark in there as well. Use array notation to check it:

Un-hijacked. Next time don't be sorry, just don't do it.

Moved this to the actual QualityStage forum.