I would like to have strict affinity mode too. In our schemas we use check constraints to enforce strict affinity. Unless you're working in a dynamic typed environment, I can't imagine why you would want to have inconsistent data within a single database field. Also for consistency with (every?) other database engine out there, a strict affinity mode would be good. Strict affinity will also benefit all wrapper writers who write wrappers following a framework that assumes strict field typing (which I think is pretty much all of them since all other db's have strongly typed fields).
Thanks, Sam On Feb 8, 2008 11:09 AM, Ken <[EMAIL PROTECTED]> wrote: > I second the strict affinity mode as an optional feature, for the same > reasons as Lee. > > A while back I ran into a problem while using the bit and feature of > sqlite and got unexpected results because sqlite changed the type from a > 64bit integer into a real. (I think)... In this case it would have been > simpler to debug, if there had been a type conversion warning or a failure. > > Regards, > Ken > > _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
