Subject | Re: [IBO] TIB_ColumnText and strings that are too long |
---|---|
Author | Nando Dessena |
Post date | 2006-01-11T08:51:33Z |
Martijn,
M> How do your users KNOW they defined something in the wrong way.
the database transforms input data in many other cases: CHAR values
get padded, literal numbers passed as strings are converted to
numbers, functions like CURRENT_TIMESTAMP are evaluated/expanded,
DEFAULTs are applied, BEFORE INSERT and BEFORE UPDATE triggers may
change input values, and so on. I guess you could call it
normalization. To me, it's pretty straightforward and obvious that
long strings are silently truncated if they don't fit, and I don't
remember having to worry about it in any other component set, but
since I've been using almosts exclusively InstantObjects lately, and
there are only strings there, my memory may fail.
To account for this, even as an option, will make IBO slower. How much
- that depends on how smart Jason makes it - but it's not going to be
free.
Ciao
--
Nando Dessena
M> How do your users KNOW they defined something in the wrong way.
the database transforms input data in many other cases: CHAR values
get padded, literal numbers passed as strings are converted to
numbers, functions like CURRENT_TIMESTAMP are evaluated/expanded,
DEFAULTs are applied, BEFORE INSERT and BEFORE UPDATE triggers may
change input values, and so on. I guess you could call it
normalization. To me, it's pretty straightforward and obvious that
long strings are silently truncated if they don't fit, and I don't
remember having to worry about it in any other component set, but
since I've been using almosts exclusively InstantObjects lately, and
there are only strings there, my memory may fail.
To account for this, even as an option, will make IBO slower. How much
- that depends on how smart Jason makes it - but it's not going to be
free.
Ciao
--
Nando Dessena