DSXchange

How did you look at your reject file?

Mike

Sounds potentially like that old varied behavior with datasets sometimes storing varchar with fixed sizes. Maybe orchadmin copy defaults to that behavior. You could try setting the environment variable that controls the behavior. Raise the issue with your support provider. You could always create a ...

Check the system requirements for your specific version of Information Server and then try it with a supported browser.

I haven't checked in quite a while, but IE and Firefox used to be the only browsers supported. And even specific versions of those were required.

Mike

Good advice from Craig as usual and particularly valuable for your scenario since he has expertise in both tools. I've always been a firm believer that once you've chosen one of the top enterprise ETL tools that it's a fool's game to switch. Mr. Client, you're going to spend all of this big $$$ on a...

If you have the Data Quality bundle for Information Server, then you will only have access to the DataStage core. Most of the special purpose stages will not be available to you.

Verify your Information Server bundle.

Mike

With something like this I would suspect some potential metadata corruption causing the issue. Are you doing a regular compile on your recompile or are you doing a force compile? See if the error repeats each time with a force compile. If you haven't already, export the job, delete it, and then reim...

Craig's very detailed explanation is exactly how I would approach it. Also be aware that you will miss cases where the column gets mapped to a different name and that other column also needs its size adjusted. Lots of risk. You'll have to regression test it all and fix anything that your mass update...

Is it always a single starting letter?

If yes, do 2 lookups: 1) full string, and 2) first character.

You could make the second lookup conditional on not finding a match with the full string.

Mike

If you are using a join stage, check your link order. Your source dataset should provide the data for the left link and your reference dataset should provide the data for the right link Your results are indicative of having them backwards.

Mike

Since you seem to be out of ideas...

I wouldn't be running Windows commands even on a Windows installation. Take advantage of the MKS toolkit and run a unix-style find command inside a unix shell.

Mike

2 distinct lookup keys means 2 lookups: Lookup1 -- reject link --> Lookup 2 -- reject link --> Additional Processing | | | success link | success link | | Trash Trash Since you want to drop your matches, you would use the reject links for continued processing. Mike

Try putting your ramdisk into its own non-default pool.

Mike

Scroll up and read Craig's first reply in the thread. That pretty much sums up what you would need to do.

Mike

I went back and reread your original post... and took note that your output was a parallel dataset. In my quick test job, I just used a peek stage after the modify. I substituted a dataset and the microseconds disappeared. :shock: So I think we have a repeatable bug with modify output to a dataset. ...

I just whipped up a quick test job and am getting the expected microseconds. Here is my modify spec: OUTPUT_VALUE = timestamp_from_string["%yyyy%mm%dd %hh:%nn:%ss.6"] (INPUT_VALUE) My OUTPUT_VALUE is defined as a timestamp with the Microseconds extended property and my INPUT_VALUE is defin...