On Fri, Jun 15, 2012 at 3:46 PM, Vadim Zeitlin <[email protected]> wrote:
> 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?
>
Sounds like a good change to me!
Stephen
------------------------------------------------------------------------------
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
