DSXchange

you could just run your job via the dsjob -run command and for status put a command like RETURN_VALUE=$? to get the status of your previous command and then print that to a file You should also look into the use of the -jobstatus option rather than the -wait option. Rather than return the 'standard...

my question regarding Ken's suggestion is that would not joining a 80 mill table with another big table, be slow in itself? Not if it's done properly. We do this all the time, it's a matter of ensuring the query is as optimal as possible. If it takes hints or an additional index, so be it. The net ...

The key here is to not load all 80 million target records into the hashed used for lookup - there's no need for that. That's what Ken explained - a method to only load the natural keys from the 80 million target records that match up with the staged incremental data. That way your lookup has the min...

Kris isn't processing 80 million records, that's what's in the target.

Sure! Just think that at the end of the day they'll basically be the same. No harm in checking it out, of course.

To me, that would imply that the user you are connected as doesn't have the grants they need to execute the procedure.

kris007 wrote:Now, this incremental data, I need to load into the target table based upon the keys found or not found. It is in this second part, where I had a problem. Please let me know if you got any ideas as I didnt seem to follow your post.

Kris, that's basically what Ken explained in his post.

The scripts will either need to be in a folder in your Project, or you'll need to create a link from it into the Project. Then yes.

You could also use a hashed file to perform the grouping - reading from and writing to the same hashed file, keyed by your 'group'. If the record doesn't exist simply write it. If it does, do your aggregation with the current value and the looked up value, then write it back. This way the records do...

You either need to know how many records you will be processing or you need to land the records first to a flat file and append a known 'end record' to the file. Either way gives you something to recognize as the end of the line so you can dump your last data set to the target.

Or you could simplify things tremendously by 'cluttering up your job design' with a hashed file between the sequential and OCI stages.

Out of curiousity, why the restriction?

As noted, this is typically caused by installing 'Service Patch 2' or SP2 on your Windows XP client machine. If that's the case, then (regardless of your version) you'll need the 'SP2 Patch' which you can download from the eServices support website.

If that's not the case, let us know.

That non-zero value that Index() returns is actually the starting position of the sub-string if it is found. The nice thing about that is, if you don't care where the sub-string is found but only if it is found, you can use that as a boolean. For example: If Index(Link.Column,'ADDDED',1) The...

As long as your operating system supports positive numbers with the 'head' command, I suppose so. On H-PUX it throws the following error:

There is a patch available - it's called 7.5.1A... or, very shortly, 7.5.2.