DSXchange

Simple, if your lookups can truly be 'case insensitive' then just upcase everything for your keys. Upcase the values in the hashed file. Upcase the values coming in you need to check against the hashed files.

Use UpCase on the incoming value before you do the lookup... or you can do it in the actual derivation of the lookup key.

Assuming the target field is a TIMESTAMP and not a DATE, you'd need a couple of things. First a VarChar field to hold it inside the job and then User Defined SQL to issue the TO_TIMESTAMP() as that datatype is not yet officially supported. That's an opinion, btw, never had to actually deal with them...

Process as in 'read' or 'create'? Read? It would need to come in via a Folder stage and I sincerely doubt there is any way it would handle a file of that size. Write? Yes. Hope you're not in any hurry, however. And since it can't create a file larger than 2GB, you'd need to chunk it up but at least ...

Look closely at your data, as simply adding the count function inside the field function is not the issue. Did you try resetting the job so we can get more specific information about the phantom? You can also do the count outside of the field function first to determine if there are any delimiters i...

You can't just arbitrarily move core stuff around like that.

Free up some space if you need to. Move it back.

First off, this is an Oracle problem not a DataStage problem. Secondly, it's an Archiver error, a problem with regards to the archiving of the redo log, usually means the archival location is out of space. This needs to be resolved ASAP before it causes the database to shutdown when it runs out of r...

You could also try staggering their flight times so they're all not clogging up the runway at the same time.

Perhaps just a 5 or 10 second delay between job runs would clear that little problem right up.

Granted.

{Wipes the sweat back on forehead}

Sometimes it's the typical Windows issues with DLL versions and other software updating one that another application is dependant on. Or things just get... horked up. A reinstall is pretty painless and corrects those kinds of errors. If you still have problems after that, investigate "the patch".

If it's only "once in a while" then I'd say that can be considered normal. There are certain operations, like a double-click in the wrong place at the wrong time, can cause 'automation errors' and crash you back to the desktop. There are a couple of things you can try. First would be to reinstall th...

Windows.

One of the biggest reasons to not run jobs with the Abort after X Warnings option set to Unlimited.

Basically, you take the SystemReturnCode value and pass it back out as the exit status of the script. In other words, you've got to propogate the error encountered back up the food chain so that your DataStage job will notice that there was an error inside your script.