DSXchange

Look into the use of the 'Trigger Column' Output mode on the Transformation Settings tab. Each time the value in that column changes, it splits off a new XML file. Arrange so it changes every 60,000 records.

That... doesn't make much sense to me at first blush. I'd need to build a test case to see how it behaved here but I don't have time for that right now. Perhaps someone else has some thoughts on the matter in the meantime?

How much work have you done with stage variables? When used in a certain fashion, they allow you to compare a value from the current row with a value from the previous row. You can do this to 'detect a change in your grouping column' such that you know when that first value per group has hit the sta...

Why not make sure your data is sorted properly first and then use stage variables in a Transformer to do 'group change detection' and constrain it to only pass the first record found per group?

Why does it abort? How does it abort? The whole point behind setting up Environment Variables and using $ENV in your jobs is because the project specific value has been defined in Administrator. Have you not done that?

Ok, let me ask this. What version of the Oracle client do you have installed on your DataStage server? When I've had Oracle related issues like this, my Fault Type was 10, not 11, but perhaps it is still an issue here. I see your database version is 10gR2, I'm specifically wondering about the client...

Well... a 'brute force' Old School method would be to export the entire project and then use your editor of choice on the resulting .dsx file to do the string replacements you'd need for this. Re-import and re-compile. There's probably some way to do update sql against DS_JOBOBJECTS and make the cha...

You don't need to. The only time you need to 'pass' any parameters is when you need to override their default value.

That sounds... familiar, as in been a problem for a long time.

Keep in mind the fact that you wouldn't *need* to run a separate audit job after each job completes, but could do so once after all jobs have run. For sql from routines, you'd need to leverage ODBC via the BCI or BASIC Call Interface, not something for the faint hearted. Never mind the fact that the...

I wouldn't even consider doing all that 'after job' in a routine. I'd suggest the routine simply lands the data ready to be consumed and then have a 'regular' job that reads all of those files and does the actual load of them.

Job Parameters or hard-coded values only. There's no mechanism to send a stage variable to an after-job routine as an argument.

Google should turn up a ton of links on the subject, for example this one. The concepts are similar across all databases. Again, questions like this really need to either go to your DBA for Progress specific answers or through your official support provider back to the vendor for guidance, unless (o...

If anyone did, they would post them. Have you talked to your Progress DBA about this? My Progress days are way behind me so can't really offer any concrete advice except to see if there's any way to do a 'dirty' or 'uncommitted' read over ODBC. That's a 'standard' way to get around record locks but ...

If that doesn't help, consider having a View created that implements your too long and complex join. That way it's just a simple select to implement.