DSXchange

You're trying to insert a NULL value into a not-nullable column. I suggest you either put a constraint in the transformer to eliminate rows (use the ISNULL function) or find the reason you're getting nulls if they are not allowed in the data.

Resizing hash files implies that your hash files have some persistency. I would not call this a best practice. There's a difference between right-sizing a hash file that is cleared/created with every one, and sizing a hash file for persistency. If your hash file is used in a transient work nature, y...

First, you're posting in the wrong forum. Server questions are for the Server forum, this forum is for Parallel jobs. Second, I'm trying to follow your wording, but it's confusing. If you're writing to a hash file and referencing it as well, you have to NOT use any read or write caching, as reads wi...

Please state your problem clearly. Your question makes almost no sense. We don't like to guess at what you mean. You haven't stated database technology, format of the source date, data type of the target.

If you don't like a space, your logic will put a NULL in its place. If it's a not-nullable column, then I suggest you use a different value to replace the blank or space.

No, there's no special date. Why not just do a LEFT(yourdate, 19) or FIELD(yourdate, ".",1) instead of all the manipulation you're doing. Everything is a string inside DS, so just lop off the last 4 characters.

Make sure you don't have an Explorer session looking in the hash file directory, as you won't be able to delete and recreate the hash file.

Could be an issue, one customer of mine uses OCI8 with 8i client to talk to 9i databases, but OCI8 with 9i client talking to 9i, not sure. One last thing to look at is if you have row buffering turned on. Search the forum, but this is a finicky feature and you may wish to try turning it off after yo...

Well, consider that Oracle is giving it away for free . What does that tell you? It tells me that no one will buy it. I've use it, I consider a piece of junk. It's method is "do everything inside Oracle". You have little or no incentive to structure things in a well-staged manner. It's highly graphi...

Since you've looked at the &PH& entry, your next step is to identify the transformer stage that blew up tragically. Was the job running any kind of after-stage routine or after-job routine when it died? A lot of the time, these subroutines can have issues such as calls to other subroutines t...

Your target is DB2, that little nugget of information makes all the difference in the world. The DB2 plugin has this pesky quirk, unlike ALL OTHER STAGES, that likes the date in the INTERNAL format. Search this forum, we've covered this lots of times. Either set your metadata on the DATE column to C...

This is irritating. IF YOU ALREADY HAVE A DATE, YOU DO NOT USE ICONV. If you have a string of text that looks anything like a date, use ICONV to turn it into an integer date value that DS understands: ICONV(yourdate, "D"). Now, to format that internal integer value into a formatted date, use OCONV: ...

OCONV formats dates from the internal integer value, not ICONV which tries to recognize dates and turn them into the internal integer value.

Or, you could create the INLIST function that I posted at m and make this really easy: if NOT(LINK_LOOKUP.NOTFOUND) and INLIST(trimb(LINK_ROLLUP.ORGTG_IBT_N), 2610,2710,5810,1409,7526,1426,5837,9405,5745,3145) then LINK_ROLLUP.CASH_A + LINK_LOOKUP.CASH_DEP_R100_CC_A else LINK...

What do you mean by "size"? Row count or character count or total disk consumption? DataStage has no facility for sizing a file before processing. Yes, you could have a job read every row of the file, collect the total number of characters in use and row count. If row count is what you need, you cou...