DSXchange

It is clear that the "%" character is being interpreted, so you will need to quote it in some acceptable manner. Typically you will either surround the whole string with quote characters or escape the % sign using "\%". I would try the 2nd method first.

You would convert it to internal format, then back to display format.

Have you tried the option to export as an XML file? That might make a difference. I don't know how you get such long lines, as the object code is UUENCODEd to 80 characters or so.

just4u_sharath wrote:Routine activity always fails if returned value is other than 0.

That is not correct.

Or are you talking about a job Before and After subroutine?

The unix cd isn't necessary, but the poster needs a "cd" and a "lcd" command within FTP to specify the source and target paths for the transfer.

Well, when you go to your favorite SQL tool and enter what do you get (after entering a value for :1)? Does that work?

Your problem is a bad date format. Use "'DD-MON-YY HH24.MI.SS. FF'"

I see - that is also what is causing his ftp script to fail, instead of a "cd" in step 2 he needs to add the ftp command "lcd" to step 3.

The Parallel Job Developer's Guide documents the "fabs" function, which will do exactly what you want.

Fix Pack 1 addresses a couple of parameter set issues, including problems when using $ENV settings. Perhaps your problem is fixed in this pack, which has been around less than a month.

Ray - in the case the "cd" is issued as part of the ftp script so it is a valid (and necessary) command

You will have trouble getting decimal places from the ABS function since it returns an integer result. I don't have the docs available but seem to remember that there was some decimal function that could do this, or you could do "ABS(In.Data*100)/100" for decimals variables with 2 places of precision.

No, by splitting it into 2 reads you have shown that the bottleneck is not the network . You should look into the detail docs for Oracle enterprise and get parallel reads for this view working, then you can remove the 2nd stage and use the parallelism from the APT_CONFIG file to drive your throughput.

I haven't used that option for PX Oracle but would think that you should be able to get it working. But it might be the case that the read speed is being limited by network throughput and not the Oracle database (unlikely in this case, but still possible). You could try doing what we used to do with...

Hello Maik and welcome to DSXchange.

The job log history is not available for export and re-import in another project. There are routines which will let you read the log entries and you can put them into some table or file; but there is no (documented) method of loading log entries.