Hi all > Yes, that is what is expected, but in the case of SQLite, the column > type changes to SQLITE_NULL for nulls and that is a problem in > squeakdbx now. I think column datatype should not be stored in the > resultset in the case of sqlite. Other databases don't behave this > way (as far as I can remember), so, overriding moveNext for sqlite > would probably be fine.
I've enhanced the way to find out what is the data type of the column even if SQLite3 returns SQLITE_NULL as column type when one row contains a value of NULL. SQLite3 provides a function sqlite3_table_column_metadata() which returns the original column information when SQLite3 is compiled with the marco SQLITE_ENABLE_COLUMN_METADATA (which should usually be the case). The enhancement is available since SVN rev. 362 Norbert ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ libopendbx-devel mailing list libopendbx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libopendbx-devel http://www.linuxnetworks.de/doc/index.php/OpenDBX
