DSXchange

There's already an awful lot of "specific details" here. If you have a similar question or issue, why not start your own thread? Then we'll know what version and what specific questions you have.

A constraint is an expression. If the expression evaluates to "true" for a row, it is passed down the link. If the expression evaluates to "false" it does not. Simple as that.

Transformer constraint would be one way.

Post your stage variable derivations, seems that one of them might not be kosher.

An exact search for "Requesting delayed metadata" returned 23 matches, did none of them help?

Then you need to fully explain your job design / layout in gory detail, particularly how your are reading from and writing to the hashed file in question including all settings in both stages. Reading / writing to the same hashed file in a Server job is fundamental stuff and works just fine when set...

Field() not Fields() and Andy already posted that particular solution.

Before we go down that potentially rocky path, why not just make sure the lookup's Pre-load file to memory option is set to Disabled and see if that "fixes" it.

It's not an error, I'll wager that the next time you called it the "error" was a 4. Then a 5. What you are actually seeing is the next surrogate value being returned by the routine which is exactly what it should be doing. Your issue is the 'Automatically handle' compiler option you've ena...

You need to handle the Field Mark that is part of the returned value. It's been posted here ad naseum but one more time... Convert(@FM,"",EC_StageName.$CommandOutput)=0 -or- EC_StageName.$CommandOutput<1>=0 The code Andy posted should have worked just fine, I'd suggest double-checking it o...

Don't cache the hashed file for reading. That or read about what the 'Locked for update' option entails.

Use Field() to fetch the first field from a 'space' delimited string, then it won't matter how big it is... or isn't. You cannot simply fetch 10 characters when your date size is not fixed.

No. And especially odd is the fact that the job is not aborting as that is what would normally cause a rollback of records. Again - patches? Fixpacks? Are you all current?

Use Field() rather than substring to get the date portion. You could also try using just "D" in the IConv call rather than your specific mask with those sizes, it is pretty darn smart about figuring dates out in its own.

What happens if you solve the truncation problem? Does everything then load correctly?

Regardless, I've got no good suggestion as to what might be going on. I would suggest both involving your official support provider and ensuring you are up-to-date on patches.