DSXchange

You seem to be implying that the bottleneck here is your source query. What database are you using? What stage? Without adding an index over the last_update_date pretty much the only way to speed up a simple select like that is to introduce parallelism. In Oracle, that would mean a PARALLEL hint. An...

In Server you would set any such 'commit interval' to zero for an 'only commit once at the end' load. Is there no such equivalent in PX?

Add a key column. Populate both with the same value. Join as before.

Yes. To both.

Please start a new thread of your own rather than hijack this Resolved one. When you do, post the full error message you are getting.

Sure. Just define it in each project with it pointing to whatever tnsnames file is appropriate for that project. It will then automatically be set for all jobs that run in that project.

Of course, individual jobs could have that environment variable added to them and then overriden if need be.

Bummer. Then, as Ray notes, you seem to be firmly in the grip of the Scheider Conundrum and "you're gonna need a bigger boat". Unless the Wussing Corollary applies, in which cause that won't help.

Assuming your month's day is still valid six months out.

Assuming the time taken is primarily spent waiting rather than actually compiling. Does it always take that long? If not, then I'd go with the concurrent compiler license thought.

Right. You've got the corrected syntax now but as keshav0307 points out having multiple 'not equal' checks with 'or' makes no sense. They needs to be 'and', otherwise it will always return true.

Excellent.

ps. It's not a ticket. And you close it by marking it as "Resolved" which you've done. So we good.

Nice. Put your questions in the Message body. Changing the subject in a reply can only be seen when people reply to your post and may not even be noticed then, I didn't at first nor does it seem Arnd did. Most people won't even bother to click Reply based on what can be seen in your posts. i wanna u...

Right. Go over the dreaded '2GB Barrier' and performance is dramatically affect because the hashed file will corrupt internally. Then, as noted, it's time to switch to 64bit hashed files.

Well, the Server ODBC stage has an Update action of 'Call stored procedure' so would work as shown. Does the Enterprise stage? If so, it should work in a similar manner.

Sorry, can't answer your SQL Server question but I have to ask - why a stored procedure just to do that? Why not do your updates directly in DataStage?