DSXchange

Using Entire partitioning with a Join stage will give you the Cartesian product of the inputs. You don't want to go there. The remainder of your questions are moot. Believe the documentation. The Join stage requires that its inputs be identically partitioned using a key-based partitioning algorithm ...

The Lookup File Set not only consumes rows, it builds a hash table index on the data at the same time. If your data contain many distinct values of the column(s) identified as Key, then the work of building the hash table index is quite a lot, and may well be the main cause of the symptom you descri...

No, it would be a pain to restore.

Use scripting around istool utility, using dsjob commands to generate lists of projects and of artefacts within projects.

Perhaps it needs a trailing semi-colon in the SELECT query.

Perhaps it needs, or does not need, a line terminator in the file.

Experiment with those possibilities.

Can you please advise what the actual (hex codes) values are for the first three source characters after the tag? ^Z is 0x1A (which may help you).

It appears that you are not using a compatible character map between source and target.

Probably. Though it would be far simpler to query DS_JOBOBJECTS.

In either case, the query will not be able to resolve job parameter references without being a lot more complex.

Is <job name> the name of a job invoked from a Job activity? If so, right click on the "Requesting job run" event (with the -> in its text) and choose Related Log to see the actual job log. Report to us what you find there, particularly about its finishing status. You can right click on th...

You could use the ODBC stage via a driver for text files, perform a Lookup (for example) and direct your attention to the Reject link from the Lookup stage.

Check your PATH, LD_LIBRARY_PATH and CLASSPATH environment variables.

Count the lines and subtract 2 to give the max. Use 2 for the min. This assumes one header and one trailer line.

Are you certain that there is no ^Z character in the source data? (Note, too, that this is the DOS end-of-file marker.)

If you are able to use a Lookup stage in an SMP environment chances are that it will result in a job that finishes faster, because there is no requirement to sort the data. Entire partitioning is managed via shared memory.

I agree with your expectation.

It may be that you have discovered a bug, in which case you report it.

Or it may be that you have RCP enabled on the output link of the stage immediately upstream of the Checksum stage.

That the project has to be cross mounted.

Read each row of the file as a single VarChar of suitable size (or even unbounded).

Parse and filter in a downstream Transformer stage. Use appropriate substrings (in stage variables) for the first, second and third characters, and perform the logic on those.