Walter, > Because triggers could fix the data to be valid?
> And that can be confusing, because to modern programmers accustomed to > nearly unlimited string types, varchar(x) is more about > CHECK(char_length(field) <= x) [logical-layer] than about APIs and C > compatibility [physical-layer]. Unfortunately, the SQL standard and committee has not taken that view. They expect that the developer/languages provide appropriate layers to ensure that database datatype sizing constraints are met/enforced before the data reaches the database. > It seems logical to me for someone to want to > create a BEFORE trigger that would trim varchar fields down to size, and I would suggest that this is the worse place and approach to be enforcing the field lengths. The client/user is the correct location/actor to make the decision about how a string should be shortened. Further, it would not take much effort to develop logic which performs the evaluation/validation before the data is sent, to save an extra back-and-forth with the server over the network. > failing that, would let FB double-check the length after all the BEFORE > triggers > have had their way with the data. To perform the length check twice would add needless CPU cycles for most operations. Sean
