DSXchange

Thanks Propogating did the trick! Not sure what the problem was though since I had originally defined the columns by using a Transformer stage to copy columns and then moving the link to the Partitioner stage (old habits die hard). Just to make sure, you did check the KEY attribute on each output li...

Yep, all the columns match. Works fine for Round-Robin so shouldnt be anything like that. I dont use a link collector. The partitioner is to allow me to do a parallel sort and then each stream will insert to database independently. Make sure that the key columns in all of the Output links of the Lin...

When using the partitioner stage with either Modulus or Hash option it outputs "0" for every column. Works fine for Round Robin. I am using a single Decimal column for the hash key and was going to use Modulus to ensure that records with the same value are sent down the same output link. A...

When the job process hit around the 1GB of RAM mark it soon aborts - no error message given.

This is occuring when using the XML reader to parse large files and we have noticed it with a few jobs.

Anyone else experienced this behaviour?

We have a datasource that is XML published as a URL. Obviously I could (but would rather not have to) use some sort of script to extract this to a file to be processed by DataStage, but does anyone have any ideas on how this could be collected directly by DataStage? The XML Pack 2 reader seems to be...

If you set transaction size to 1 then every record is a transaction, hence your problem if you hit Oracle with more than 255 records at once. If you set transaction size to say, equal to the array size, this should remove the limitation, while still performing a regular commit. I havent tested this,...

Is this the case with Transaction Size set to 0? I would have thought that with that setting then only 1 of the possible 255 transactions would be counted for the whole job. Array Size .... Performance benefits tend to tail off at higher numbers, and there are some tricky issues with values over 255...

roy wrote:Hi,
You can however filter the view not to show "deleted" components.

Nope, this doesnt work when I delete directly from the VC project. I assume it works only when the delete is done from the VC interface itself.

VC has a copy of the job. It is a project so you can delete within the VC project. Sorry, when I said I delete the job from the project, I meant from the VC project not the original project. It appears that VC stores another list somewhere and does not refresh based on the actual jobs in its project.

Try filtering the view (e.g. last 100 entries).

When we try to delete a component we get the following error: "Unable to delete component through Version. Would you like do so in the Manager?" If I delete the job from the project it still appears in VC (regardless of the user option). Any ideas of what might be stopping me deleting in V...

They do not appear in this case.

I'm guessing the error is occuring during this process.

ray.wurlod wrote:Same advice to you, Ian, also look at the start up entries to determine the actual SQL statement that was sent to the database to be prepared.

I am having the same problem, but in my case it may be due to using a bit more complex SQL (i.e. contain subqueries). If I run either the UPDATE or INSERT statement by themselves it runs fine but put them together and I get the abnormal termination. Error is DataStage Job 2057 Phantom 11843. Doesnt ...

The easiest way is to access the Logs for Oracle Materialized Views to identify the changes made to a table. These Logs are implemented as tables and can be created without needing to actually create the Materialized Views themselves. I suggest reading the Oracle Data Warehousing Guide for more info...