DSXchange

Sorry, had to ask. And you said in your other thread you did a root install, yes? Hmm... nothing helpful to add other than the nagging suspicion that I've read about this issue before on the Solaris platform.

Anyone?

It's only not supposed to happen if you are logged in as dsadm when issuing this command... are you?

You'd have to call IBM / Ascential support for that, I would think. There were a small number listed on the eServices website in the past, but nothing that listed everything to my knowledge.

And you are positive that this Oracle sequence exists in this other database and your user has all the grants it needs to it?

Between the two actions? Pretty much what it says - which one it tries first. The first action must fail for the second action to fire. Best to get it the 'right way round' so that you don't waste too many cycles trying the 'most likely to fail' action first.

skaruturi wrote:When we dsx form and change the environment,

How about you rephrase this bit? Not really sure what you mean there.

Aha! See if this helps.

Where's that link to Ken Bland's article on hashed files... I know it's around here somewhere...

If you are asking if you can do the same with one of those silly double-action actions - Insert Then Update or Update Then Insert - the answer would be no.

Bulk as in ending up as Junk email? Nope, just plain old not showing up.

Yah, must just be me... or yet another comcast.net issue. However, I am receiving emails from other places, just not here. Ah well.

Ray - - I would think you would be, seeing as how you respond to pretty much every darn thread here.

Well... there ya go.

What happens when you run the job? That's the key... this could just be a known 'View Data' issue with the File Pattern option. Don't have access to PX or I'd check...

Not really, but let's soldier on. What exact version of 7.x do you have? Early versions required jobs to be recompiled to pick up changes to Environment Variables from what I recall...

Let us know what your DBA says.