DSXchange

Not much to say except that means every row is committed individually which is about the slowest way to load data on the planet. Involve your DBA, have them monitor the database, particularly the undo/rollback usage and space using the old values. See if that sheds any light on this.

Ah... tend to forget about them darn things, not having had much of a chance to play with them anywhere.

I was wondering much the same thing, how the expression was being evaluated... perhaps the '1' simply means 'true' here. I don't think we're getting the whole story.

If you are certain that your bogus 'update' never fires, then it's time to involve your official support provider. Only other thing I could suggest would be to see if there is an updated Oracle client version available as I've seen things like this from Oracle bugs that (usually) get fixed in later ...

So... no matter the input, the output you get is always "1"?

Probably not long enough.

ps: your posted syntax is just fine.

How about... more than one? :wink: There's no way for anyone to answer that, too many variables in both the hardware and exactly what your Sequence and the jobs it runs do for a cogent answer. You have to do something like they did at Los Alamos when they tickled the dragon's tail - ramp things up u...

You would have build something to first encrypt them and then job control to decrypt them on the fly when it sets the value and runs the job. None of this will help with running from the GUI and everything would be in clear text in the job's log. You need to rethink this 'requirement', find some oth...

Grep for processes, something along the lines of:
Should get you started. As to the general 'busy' question, work with your SysAdmin for that.

There is no 'exact' and not much to help to be given other than 'run fewer jobs at the same time'. Typically this means start rather than run as it is a startup issue. On a 'shared server' you'd have to do this at an enterprise level, working with the other teams to minimize the problem. How busy is...

Updates based on non-indexed fields will do full table scans, so it is always in your best interest to avoid that - especially for anything with the word 'huge' associated with it. Me, I would never design a job using Upsert in a situation like that unless (maybe) you used 'Insert then Update' knowi...

asorrell wrote:I do know of one site that has TPT working with 8.0.1.

According to Andy, it *is* available for your version. Check with your official support provider if you don't seem to have it.

I know that Informatica has plugin for previous versions. I wonder that it is possible to do the same in datastage previous versions. I have no idea why what Informatica has or what versions they have it for would have any bearing here. And I wonder why you wouldn't just upgrade? Far simpler than a...

Have we just gone from one table to 'issues with all the tables'? And are we really talking about 10g rather than 11g?

Never found any need for a patch, this is easy enough to never trigger by proper job management. And by 'easy enough', I mean I never had to go out of my way or worry about this in any way in spite of typically needing to run many (many) hundreds of jobs daily. YMMV of course, but that's been my exp...