DSXchange

Was going to link to that one as well but it is so UNIX-centric that I mostly decided to stick with this from the wrap-up paragraph: "If the above tests do not isolate the cause of file system i/o problem, then it may be necessary to contact Information Server support for assistance in performi...

Not sure it applies much to writing a fixed-width file but wanted to point out that your "Null field Width" values need to match the size of your char field. So: Edit Row: * COD_MDL_ORG String Type : Field Width = 4 Nullable / Null Field Value = " " * TPO_RPT String Type : Field ...

A "NullPointerException" is generally thrown by a code bug. I'd contact your official support provider for help with that one.

Interesting. I was assuming, much like Ray, that this happened when multiple instances were stepping on each other. But if it can happen while the job runs in isolation that's a whole 'nuther kettle of fish. I believe that STATUS of 2 means "file not found". If you were on a UNIX server I'...

Found this in an older post:

Kryt0n wrote:In order to get the fixed width file format recognised I have had to go to the Columns tab, right click, choose Edit Row and set a Field Width value for each row (i.e. the Length field despite being set, doesn't appear to be relevant to the field width)

You can't, at that point the parameters are just text. You need to build the file on the fly with the parameter values substituted in, ready to go.

Have you made any progress on this, Tony?

As am I. MQ is not my forte.

Split to your own topic, linked back.

Or with this config file, perhaps?

I'm guessing you'll need to run something like this: VERIFY.SQL SCHEMA {ProjectName} First to see what it says and then perhaps add the FIX option to the end of it. But in your shoes I'd wait until someone like Ray wanders by and confirms or denies that. In the interim, wouldn't hurt to run it and s...

All of those tests just prove that the instance is up and accessible. However, each could have their own unique Oracle environment setup - without you validating that they all use the correct ORACLE_HOME for instance and library path, it doesn't really tell you all that much. Other than the fact tha...

Make sure there's an index in the target table supporting your update WHERE clause. Sounds like there isn't.

Assuming both the database and listener are indeed up (confirmed by the DBA?) then more than likely you're using the wrong connection information in the job.

APT_ORACLE_PRESERVE_BLANKS is probably what you're thinking of. However, "blanks" here equal spaces as in trailing spaces during a bulk load so I'm not sure it's going to help. An empty string will be turned into a NULL in Oracle regardless.