DSXchange

No... it should just log a warning if any data is truncated within your transforms. Too many may cause the job to abort, depending on settings. Your *target* is rejecting the row.

I don't know of any 'global settings' in Oracle (our target, you don't mention yours) to allow that, AFAIK it is your responsibility to ensure no data fields exceed their database counterparts.

BTW, this would imply that your metadata for your target is not correct.

-craig

Hi,
since you found that some columns get truncated there is only 1 way, in my opinion, to proceed:
inform the relevant people and let them decide, should the table scheeme be altered since "data is lost" or sould the data be truncated.
if they decide to change the table your home free and if they want to truncate it you can do it in a transformer prior to inserting it to the DB and avoid the warnings/job aborts.
Good Luck,

Roy R.

What is your target database and server platform? (this may be key to the whole issue) I really don't recall the behaviour you are mentioning for 4.0 (been 'using' since 3.1) so someone else who knows better jump in here, please. As best as I remember, it has always been the case that you needed to ensure your data would 'fit' in the target database - at least *Oracle* requires that and there's no way around it.

Meaning, your metadata has to be correct and any oversize fields need to be truncated in your transforms. This will generate a warning each time it happens if you let DataStage truncate the data, this can be avoided by substringing it yourself.

-craig

Yes,
I have also seen this functionality.But my guess is not inserting the record(6.0 Feature) is better than the truncating and inserting feature(4.x).
Which in 4.x u needed to check the data length before inserting the data as otherwise the truncated data used to get loaded.
Not sure if we can set this behaviour as a property somewhere.