DSXchange

The other typical approach is to count the number of records to be processed and pass that in as a job parameter. Then you can compare that number to @INROWNUM and know when you're there. Works best for flat files or other situations where it is simple to determine the count ahead of time. I've done...

A 32bit hash file can't be larger than 2GB. However, you'll find lots of traffic here on the subject of creating 64bit hash files which don't have that limit. By 'SQL solution' I meant having the source query that builds the hash file compute the max timestamp for you, rather than pumping all rows i...

mhester wrote:You are correct in calling the routine with jobname as this routine does not require a job handle.

Bummer. Couldn't find any reference to it in the help, and since the other DSGet* functions require it...

I'm not familiar with DSGetLinkMetaData (?) but none of them work by Job Name - they require a Job Handle, which is something entirely different. You can do two things. Either use DSJ.ME for the handle to indicate the current running job or attach to the job first by using DSAttachJob and then use t...

All jobs? Some jobs? Just one particular job?

Without more details... any chance you are running out of disk space where DataStage is installed?

You could also use a variation of the SQL Keith posted so that the source database does all the work of figuring out the max(timestamp). I'd still put the result in a hash and leverage that in your job.

Either way.

Can anyone help me in storing the log files, generated in compilation, in a separate directory. The confusing part to me is the 'generated in compilation' part of that sentence. It doesn't mean the normal log files from when the job runs to me... but that could just be me. Perhaps the OP is after s...

One approach is to build a reference hash with your current business keys and whatever other data you need to know about the current record. In your case, that would (at the very least) be the timestamp. Order the inserts into the hash by business key, timestamp ascending to take advantage of the de...

Bitmap Indexes are not something you want to be updating, if you can help it. Found this quote at a site I have bookmarked: You must also be concerned about high-volume updates. Bitmap indexes are notoriously slow to change when the table data changes, and this can severely slow down INSERT and UPDA...

Forgot about that little conundrum. From the header of the file: :: Required Components: :: dsjob.exe (Windows Version) :: (also requires vmdsapi.dll) :: Advised to place both files under Windows System directory. From what I recall, I took the 'dsjob' executable and the dll from the...

Another option to keep in mind... for the future. You can dynamically generate your SQL statement and write it out to a flat file. Then, in your stage, set the Update Action to 'User Defined SQL File'. What you then put in the SQL area is the pathname of the file. Not something I've used alot, but i...

It's a local variable, something that can come in very handy - at least in Server jobs. Not positive about their role or pros/cons in PX jobs, if any. This post should help.

Exactly. You'll find Oracle trace files in the 'home' or 'current working directory' of any process being traced. As Ray notes, for DataStage jobs, that is the project they belong to.

Those look like Oracle trace files. I'd have a talk with your DBA.

ray.wurlod wrote:For whatever reason, DRS uses the Oracle notation for parameter markers (:1, :2 and so on) despite the fact that no other database does so

I don't know about other folks, but I vastly prefer the Oracle numbered parameter marker style over the other 'question mark' way of handling them.