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