Just to make it crystal clear, to a developer actually calling the SQLite functions (I'm talking about [ PrepareSQL_v2 ] and such, not [ select * from table ]), SQLite is TYPELESS which means there is no data type that is kept track of for any field. This means that even if you define a column as NUMERIC, you're still able to put 'ABC' and get a successful insert.
So a statement like this: create table Test1 (Field1, Field2); is going to be treated the same as create table Test1 (Field1 numeric, Field2 char); is going to be treated the same as create table Test1 (Field1 char, Field2 UberwonderfulTypeCast); At the Wrapper level, it doesn't matter what kind of type you define for a field. SQLite will essentially ignore the type and allow an insert of any type. You could put a BLOB in a BYTE type field and it'd happily take it with an insert. Now, at the point where the SQLite code is telling the OS to write data out, it internally knows the type of data you're putting out. So it knows that you're writing a number, a string, or a blob, and that is JUST for handling data efficiently, and you'll never have to concern yourself about that bit of data (Unless your one of the SQLite dev'rs) but above that layer, your wrapper is going to be making the final decision on what data you're pulling out is. So if you were trying to pull a boolean value out, and you were getting unexpected results when the field value was 1, 0, or -1, then your wrapper is internally calling a check on the field type and validating the expected return and failing if NUMERIC wasn't defined. _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
