DSXchange

Use a Sequential File stage to capture rejects, not a Hashed File, you could be losing records due to the 'destructive overwrite' nature of hashed files depending on the keys you've defined.

You already know the "full syntax", you've used it correctly just on the wrong "file". Your log file's name was explicitly mentioned in the error message, however to look it up simply query DS_JOBS:

Never heard it called that, are you perhaps thinking of the Nested Condition stage?

In other words, you need to ensure each partition includes all values for the grouping keys in that partition.

shareeman wrote:I've resolved this issue.

My issue pertained to a specific library file that was missing.

Could you please share the library file's name and what you needed to do to bring it back from the missing? It would help future searchers who come here with the same issue.

Thanks!

Right... but it was news to me that you can rename categories there now, that was not possible in earlier versions.

Sure! Simply append it after the job name using a period (aka 'dot') as the separator:

JobName.InvocationId

All of the information that would have been strictly in the 'Universe' repository is now in the 'open' XMETA database repository as well (including folders AFAIK) and so most of the UV solutions we have from the 7.x world no longer work or may not be the complete solution. Especially if the two get ...

It won't help, as the issue sounds like it's in the XMETA (relation database) repository, hence the need for a patch. Sounds like you should contact your official support provider.

Interesting... I should have added that my reply was strictly referencing pre-8 installations and could very well have changed in the new release. I'll need to test that when I get some time on our 8.1 server.

QuestExpert: :!: Please don't quote the entire contents of every message you reply to. There is a perfectly lovely Reply to topic button at the bottom of the post that will start you off with a clean slate. It's fine to do so to make a point or to ensure people know exactly who / what you are replyi...

I actually meant to delete them from the target not the source and then rerun everything... but either way could work.

How you access something isn't changed by the fact that it is in COMMON. So if what you've got in there is a dynamic array, you can certainly iterate thru the elements there just like you would any time / place else. Etc.

I've never had to change or add anthing to that 'header' area.

Sure, you could replace it with pretty much anything as long as you can guarantee that it isn't used anywhere in the data. Hence Kim's choice. That or just use my fancy pantsy formula.