DSXchange

Set the Transaction Isolation option back to something other than 'Serialize'.

I have UltraEdit, wasn't aware of the remote access stuff. I'll have to check that out.

For me, this *was* "regular ftp" the script was running, but it apparently had KERBEROS compiled in as an option. There was nothing for me to switch back to as far as I know... unless it is another of those things that unalias would fix!

It's a better solution for single-threaded, non-concurrent loads: get the starting value once, increment it over the course of the job and put the new starting value back at the end. Less I/O and you don't have to "lose" values in an abort/restart situation.

Did you try the search that was mentioned?

That's a DB2 question, not a DataStage one as the stage doesn't hold any locks. I don't know the answer but I'll wager your DBA does.

Reset yes, recompile no. And as noted, lack of design time information can make diagnostic efforts when there's an issue much more difficult.

Ray just talked about DS.CHECKER recently, I'll see if i can find the link.

1) Just the "Universe" repository.
2) From what I recall, it removes orphaned bits.
3) Can't help on that one.

Link added: viewtopic.php?t=127198

If it is Redhat Linux, and you are getting vim when you type vi you can just "unalias vi" to get the original vi command. I'm colorblind, so vim drove me nuts. I just put the unalias vi command in my .bash_profile so it is turned off for me when I login. Yes, it is RH w/ bash and it's not...

It would be helpful if you posted the patch number that resolved this for you.

Thanks Scott, I'll check out those links. For the record, i don't actually have a .vimrc file in my home but there may be a global one out there. I do, however, have my very own .viminfo file! Neeto.

What kind of problem are you having? In a transformer you can use the DateFromDaysSince() function as one way to do this.

In a Server job. I've only seen that error with the OCI8 stage and the 'solution' was to use the OCI9 (aka 'OCI') stage instead. What exact 7.x version are you running? Something older?

It apparently uses both a ".vimrc" and a ".viminfo", the former is similar and the latter seems to keep all of the history.

Welcome aboard. First suggestion is always to search here for an appropriate portion of the error message as (more than likely) you're not the first to post about it. For example, an exact search for "Non-pipe (or non-virtual data set) with .v in its name" find 24 other posts on the topic.