Hello again, Currently if a select statement results in a null value and no indicator is defined for the corresponding output parameter, a "Null value fetched and no indicator defined." exception is thrown. I like this very much as it doesn't allow you to simply ignore nulls while still letting you to handle them easily just by providing an indicator.
However for some reason the same logic is not used for truncations. If either output or input parameter is truncated (the latter happens in insert/update instead of select), this is recorded in the associated indicator, if any, but if there is no indicator the truncation is silently ignored. I wonder if this is really correct. It is inconsistent with null handling and also dangerous (as half an hour spent on tracking a bug due to not noticing that a truncation happened in my code attests). Shouldn't an exception be thrown if a value without an indicator is truncated? This would clearly be backwards incompatible as previously working code in which truncations occurred would now start throwing exception but hopefully the reason for this change in behaviour shouldn't be difficult to find so maybe it's still worth doing? What do you think? VZ
pgpQcyLleF8gM.pgp
Description: PGP signature
------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________ Soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
