DSXchange

If you have set the link to "unconditional" then Job2 will execute regardless of the status of Job1.

No, we mean to define and set the environment variable $APT_DISABLE_COMBINATION to "true" in your job's parameters.

You can execute TCL commands from .bat scripts and get that data. CD to your project directory and then "uvsh.exe LIST DS_AUDIT BY.DSND DTM BREAK.ON INSTANCE DET.SUP MAX DTM MODIFIER NO.PAGE". The output goes to stdout and can be processed from your .bat script.

The example buildops and routines can be found relative to InformationServer/Server/Dsdk

I've been playing around with moving jobs and sequences today and seeing if I can see your error and have been unable to reproduce it. Did you have an errors or warnings when you moved the sequences? If you move them back to the original location does the error go away, and if so - does it reappear ...

No, I never said that. Join stages work by sorting the input links (which may or may not require scratch storage or buffer storage) and then doing an efficient comparison of records from the links. Because the data is sorted, it is not necessary to use much memory, unlike the lookup stage which requ...

"Scratch" is temporary disk space, which is different from "temporary memory" but otherwise the definition is not wrong.

Just so I understand the problem - despite doing a refresh or closing your designer and re-opening it, when you try to open either of these two sequences you get an error message?

What happens if you click on the sequence in the Director and try to open the designer from there?

The DS_AUDIT hashed file contains this information. You could get this information by executing the following command from TCL: LIST DS_AUDIT BY.DSND DTM BREAK.ON INSTANCE DET.SUP MAX DTM MODIFIER If you want to put this into a text file, you could write a Server job to read this file and write it t...

Yes.

Lookup keeps reference data in memory, not on disk.

One of the basic tenets for performance is never to perform unnecessary conversions. If your source and target type is numeric for a given column then performing 2 conversion to VarChar on the way is inefficient. Likewise, a comparison of two numbers is far more efficient than comparing two strings....

Isn't that solved if you "refresh" the repository view?

No, that statement does not reflect what happens. Both methods will use memory, but the lookup keeps the reference data in memory while the join stage sorts the streams (on the join key(s)) then needs only minimal memory at runtime.

Yes, execute the command from your Windows "cmd" prompt.