> From: "Igor Tandetnik" <[EMAIL PROTECTED]> > > "Rob Sciuk" <[EMAIL PROTECTED]> wrote in > > > > The other bit of trickery involved is that in order for the value > > types to be correct (meaningful), you have to take a "step" as it > > were ... with sqlite3_step 8-). > > You can use sqlite3_column_decltype[16] without calling sqlite3_step > first. This gives you the "syntactic" type, the type that can be > inferred from the text of the statement and the database schema. > > Igor Tandetnik
Thanks, Igor, but I'm not looking for the type (either declared or affined), but rather whether the actual value is valid, or NULL. That was the point of the original post. My problems arose from the fact that it is the sqlite3_column_type() function which returns the fact that the current value is NULL, and this is somewhat counterintuitive. In my books, the data type is the type, and the data value is either NULL, or has a value in the domain of that data type. One would not query the data type to determine whether the value of the datum is defined or not. Of course, SQLite has a unique affinity model, and I'm still wrestling with this, though in my gut, I feel that along with the sqlite3_column_xxx() functions, should be a sqlite3_column_isNULL() function. Indeed, in a former life I have had a great deal of experience with SIR/DBMS, which is able to differentiate between undefined, NULL and up to three user defined MISSING VALUES per data item, and moreover to differentiate amoung them. Of course, SIR/DBMS was not a general purpose database, and specialized in scientific applications, and particularly statistical analysis where such subtlety was important. So, again, to those who offered advice, thanks, and I'm quite ok with the way things work, now that I know how to proceed -- I'm just saying ... 8-). Cheers, Rob Sciuk _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
