DSXchange

Yes, there are but I'm on a UNIX system here and cannot check, but they will have vmark/ardent/ascential in their name somewhere.

he did tell you another way. Write a job that connects to the database (a dummy read, for example) and then it is validated instead of run; the return code from the validate run can be used in a sequence job.

That is not generally the case, I never see that problem and use multiple job compile on uncompiled jobs all the time. Can you manually compile the job that is triggering your error?

The CJK characters in UniCode are in the range 0x4E00 through 0x9FFF, your 0xD00 character is outside of that and is probably not a valid character, which is why it cannot be converted.

If you don't specify either a number of messages or a wait interval then your job won't stop running; is this what you really want? Also, this is not a fatal message (I know, since our MQ job here give out this warning but that is because we want it that way) but just a warning.

It might be that you didn't clean up everything from the previous install. I would remove the files and directories and then go through the registry and ensure that all ardent/vmark/ascential references are gone. Also, what is your repository DB and is it on the same machine as the DataStage server.

The view data stage rarely gets multibyte or non LATIN-1 characters displayed correctly and shouldn't be used to see if NLS is working as expected. In your case the PEEK result is strange as the e-acute shouldn't get converted to 3 characters. What is your job's default NLS setting and if you write ...

As you've noticed, there is no join stage in Server jobs. The merge stage is an option. If one of your join tables is small and would fit in memory, you could load it to a hashed file which is then used in a transform stage lookup to join the two tables together.

You really should know better by now than to try to exhort people on DSXChange to work harder for you by stating that the problem is urgent . In addition, you didn't respond to Craig's question nor did you add what you tried and what the error(s) were. I will add one more thing, which was implicit i...

Does it compile any jobs at all or abort right away? Perhaps one of the jobs is broken and it wouldn't compile even if you tried it manually - which is one thing you might try.

While I can't use the SAP stage here, how about just making your job's character set unicode and avoiding the conversion altogether. I did a quick check, and it seems that 0xDE00 is not mapped in Unicode and thus cannot be converted to UTF-8 in any case. What character is it supposed to represent?

You will need to modify your DSParams file settings for the compiler. Go into the Administrator tool, then editing the settings for your project and DSParams. The compiler environment settings are to be found right at the top.

That is a difficult question, and I'm not sure it can be done. The schema could define default values for fields which don't validate and that value could be set to some common one outside the normal data range but that wouldn't work as a generic solution, unfortunately.

Also try a test running just a 1-node configuration, as joins are commonly erroneous when incorrect partitioning is used.

The important part of Kim's post was in the first sentence.