I agree. After many years with SQL Server and Oracle (but new to SQLite), the concept of storing different datatypes within the same field is something I've had difficulty grasping. I'm not saying it's a bad thing, but from a business perspective I can't think of a situation where we would not want strict affinity. So if it becomes an option we'll use it throughout our application.
- Jeff -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Samuel Neff Sent: Friday, February 08, 2008 11:52 AM To: General Discussion of SQLite Database Subject: Re: [sqlite] How to select Strict Affinity or No Affinity modes?Attention: DRH 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 _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
