DSXchange

If which ones fail change run over run, then I'd say you have a resource issue and the instance/server/whatever can't support that many simultaneous connections.

Cool, thanks for that. Just for the record, RESIZE does need a VOC record, does it not?

Arnd, I'm a little lost on the first sentence and unsure why deleting and recreating a hashed file would cause "bigness" issues. Seems to me that *not* doing that would more likely be the reason but I must be missing some subtlety this morning. And did you mean OVER.30? :? I'm also curious...

The port is in use, I would wager, but you'd need to start it up in debug mode to verify. Search for "bind bombed" for the gory details.

You know the forum has very little relevance to what actually gets posted in it any more.

So... "not quite". Was that strictly a forum related response or does the Master have the real explanation of the issue waiting up his sleeve for a post-forum-move reveal?

Given the fact that they allegedly "use the option delete and create a new file regularly" I would not assume 64bit addressing. Still, clarifications keenly awaited.

As noted, this can be a problem when sourcing any kind of LOB field or a LONG from a database that still uses that evil data type. If you are using none of them, then perhaps it is a bug that was reported as fixed in the 7.5.3 release - check with your official support provider: ORACLE OCI stage pro...

DataStage 'permissions' are at the group level only, so they would need to be in different groups. And you don't need to explicitly do anything to allow access, typically you would need to do something to restrict access if desired. ps. There's a posting in the FAQ forum on handling permissions in D...

Problem is there are no ".30" files in a Static hashed file. Pop quiz, boys and girls - a Type 30 hashed file is also known as?

No problem, that's why I do this. :wink: I too would think this is memory / cache related, I would wager that your in memory footprint for this hashed file grew until it would no longer fit into memory and generated the informational message you saw. After that, perhaps your updates were only stored...

First off, "Jul 31 2009" is not "MM DD YYYY" but rather "MON DD YYYY" and secondly IConv only has expectations if you don't help it so use the appropriate mask to tell it what format the string that needs to be converted is coming in as.

10g is what is officially supported, 11g would probably be fine and I don't think 12g exists yet.

My current alternative is to build an independant job to preceed my oracle load that will run sequencially. And whose only function is to truncate the table. It seems like there should be a better solution than that. I'll be curious what others have to say but to me this is a perfectly valid soluti...

Then try "Enabled, locked for update" and see if that gets any faster. You must do one or the other for this to work correctly. You *are* doing the update link in the same transformer as the reference lookup link, yes?