Kris Groves writes:
 > Hi List,
 > I'm seeing strange behavior here :

This is a sqlite/sqlite3 driver problem, not a generic libdbi
problem. The sqlite driver has to guess the column types from the
"CREATE TABLE" statement that was used to build the tables involved in
a query. The reason is that sqlite is essentially typeless. It is
obvious that aliases strain the column type guessing code. The
situation has improved somewhat in sqlite3, now that there is limited
support for data types. However, the internals of the sqlite3 driver
do not yet make good use of the improved type support.

I'll try to rewrite the sqlite3 driver to take advantage of the type
support, but I haven't checked yet whether this is possible within the
constraints of libdbi's current design. In any case it'll take some
time to implement.

For the time being you may have a look at the functions

long long dbi_result_get_as_longlong(dbi_result Result, const char *fieldname);
long long dbi_result_get_as_longlong_idx(dbi_result Result, unsigned int 
char *dbi_result_get_as_string_copy(dbi_result Result, const char *fieldname);
char *dbi_result_get_as_string_copy_idx(dbi_result Result, unsigned
int fieldidx);

These functions are available in the latest cvs version. The first two
functions return any value as a long long integer (which you can cast
to any other integer type) using reasonable conversions if necessary
and if possible at all. The last two functions return just about
anything as strings. Obviously these are merely workarounds in your
case, but they still may be helpful to get things done.


Markus Hoenicka
(Spam-protected email: replace the quadrupeds with "mhoenicka")

Sponsored by: Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at
libdbi-users mailing list

Reply via email to