DSXchange

I can... and did.

There's no such script that I could find, engine or projects.

This isn't about creating invocation ids, however, which is where the confusion is coming from. It's about running a job with an invocation id and when you ask the job what the invocation id is, it comes back empty.

Delete file and Clear file are mutually exclusive, meaning you only need one or the other. Stick with 'clear file' so you don't have to rebuild the index every run.

The WFF stage is a 'blocking' stage. Clarify something - are you saying that you need a Sequence job to stop when a file arrives at any point over the run of the Sequence? If so, there's no way to do that without having some sort of looping construct such that you do something, wait, check for file ...

AmeyJoshi14 wrote:So if the number of datasets are increased, then it will hamper the job performance..

Not really sure how you read that into my reply.

Yup, you'll find the advice re: "lib versus lib32" all over the place here.

No idea, perhaps not something us mere mortals should be doing.

FWIW, here are the permissions I see in my DSEnging directory:

For something like that, I doubt there will be any appreciable difference in the execution speeds. Use the hashed file reference methodology when the join isn't as dead simple as that one, for example when the table to be 'joined' resides in another database.

Those tables are well and truly obfuscated. Search here for DS_JOBOBJECTS for some queries that may help. Worst case, you could export the project source and use a text editor to find what you need.

Yes.

There's no such thing.

Have you checked with your official support provider to see if it's a known issue?

There's a scripts directory under $DSHOME, check there - the name should be pretty obvious.

The other issue I should have mentioned but which would have been in the search results is the fact that mentioning multiple columns in the 'create' statement creates multiple individual indexes, not a composite index. So I would suggest starting over and creating only the index over the CODE field ...

You could do that but it really shouldn't be necessary. There's a link property on the lookup itself you'd need to enable to allow a 'multi-row result set' - did you?

Then please mark your post as Resolved using the button at the top of the page.