On Thu, Sep 9, 2010 at 1:01 AM, Andrew Wood <ajw...@theiet.org> wrote:

> Because I'm writing glue code between the SQLite API and a higher level
> library which provides a standard API across several DBMSs.
>
>
Have in mind that storage class is not a 'type', it's more like an effective
way to store values compactly, you just have 5 variants (SQLITE_INTEGER,
SQLITE_FLOAT, SQLITE_TEXT, SQLITE_BLOB, or SQLITE_NULL), and even getting
affinity instead of decltype, you won't find for example DATETIME mapping
amongst them. Can you create a good interface with a higher lever DBMS
library not providing time-related types? I suppose, no. So the only
effective way is to parse sqlite3_column_decltype result. It's not that
hard, Aducom's library for delphi actually uses this approach and it works.

But if you write something universal, also have in mind that sqlilte won't
raise any exception, for example if you try to read an integer, but there's
a text stored there, you won't get an error, just zero as a result. In my
case I managed this not only by knowing the type from scheme types parsing,
but also knowing the list of compatible affinities for the given type and
when the result of sqlite3_column_type (actual type of a 'cell') doesn't
compatible with this list, I will show some warning about this result set.

Max,
maxerist.net
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to