DSXchange

Allowing multiple instances means you can run any number of copies of the same job at the same time. Let's assume you are reading from a database table into a hashed file and that your key is a numeric field in both files. If you have a single instance of a job you would have your source stage do a ...

Binary image data is usually already very well compressed. A normal compression algorithm will never achieve 20-30% on image data (assuming a common format such as .bmp, .gif, .jpeg). You might be able to use an external .JPG converter that does lossy compression, but your picture will not be recogn...

From your reply i assumed that for PX job Before/After subroutine are Server routine. That is correct. I have found out that Server routine with External function option is for only server Transformer stage and Before/After subroutine for PX JOB level. I don't understand what you are saying. I don'...

Ok, but what kind of transformation do you expect DS to be able to do with this image data? If you are only passing it through unchanged then DS will have no problem with that amount of data as long as the databases have the correct data types defined.

Kumar, same general topic as before - you've got a messed up system; playing with the UV_SCHEMA file might concievably ruin your whole installation, not just one project. You may issue a "DROP SCHEMA {schemaname};" command at TCL. I would prefer that you created an entry in UV.ACCOUNT that points to...

If an index exists on a file then DS will try to use it; if the index is corrupt the results from a SELECT will be wrong - so an export might not work and this is why the DS.REINDEX exists. If you actually delete the indexes then the DS engine will do a full table scan - it will be much slower but a...

I am fairly certain that the transform stage will not be able to transform the image data. How can it? You haven't specified what sort of modifications you want to do. DS can read and write binary data without changing it - but why do you want to do this?

DSGuru2B - you might have achieved that in your case, but those values depend on such factors as row width as well as database configuration. A commit size of 0 would be fastest - unless the rollback segments fill up.

In car terms, your question is "my car won't go more than 80 km/H. Can you make it go faster?". There are hundreds of possible answers to the question and you haven't really specified enough information for anyone to do more than give random suggestions. By using DRS instead of the Oracle loader sta...

Yes, it should be RT_BP... and I am assuming that the original poster made a typographical error. DataStage jobs and the compiler will not create a file called BP_{nn}.

Kumar, the INDEX information in hashed files is stored in the files themselves and are absolute paths - so by copying your hashed files from somewhere else you have broken the indices to all these files in both projects. It is for reasons and side effects like this that nodoby recommends doing anyth...

The files are RT_BP{nn} and RT_BP{nn}.O

Kumar, the list of indices isn't that long or difficult; but I've never seen anyone deleting them and if you don't know how it happened then most likely there is even more wrong with the project than originally surmised. You can create a new project and do a LIST.INDEX on these files to found out wh...

Rajesh,

the Before/After subroutines even for PX jobs are DS/Basic subroutines.

Do it step by step. First just write your transform stage to detect the change in values for your group change and to insert a dummy header column called "header".