1
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
5
>sqlite driver misfeatures</TITLE
8
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
10
TITLE="sqlite3 driver manual"
11
HREF="index.html"><LINK
13
TITLE="Peculiarities you should know about"
14
HREF="c128.html"><LINK
16
TITLE="SQLite3 (mis)features"
17
HREF="x131.html"><LINK
19
TITLE="GNU Free Documentation License"
20
HREF="copying-fdl.html"></HEAD
31
SUMMARY="Header navigation table"
40
>sqlite3 driver manual: A libdbi driver using the SQLite3 embedded database engine</TH
56
>Chapter 4. Peculiarities you should know about</TD
62
HREF="copying-fdl.html"
77
>4.2. sqlite driver misfeatures</A
80
>And now we have to discuss how successful the sqlite driver is in squeezing the SQLite idea of a database engine into the libdbi framework which was shaped after MySQL and PostgreSQL. Keep in mind that the limitations mentioned here are not intrinsic (except maybe the first one which is beyond our control), that is a sufficient amount of coding might fix these problems eventually.</P
86
>SQLite3 handles auto-increment columns in a fairly non-intuitive way. Only the type INTEGER PRIMARY KEY auto-increments. As a user of other database engine you might expect the row IDs to be 4-byte integers (they were in 2.x), but nope: they are in fact 8-byte integers, and therefore equivalent to INT8 or BIGINT of other engines. This leaves us with the odd "feature" of the sqlite3 driver that INTEGER is a 4-byte integer, whereas INTEGER PRIMARY KEY is a 8-bit integer type. If this were not the case, auto-incrementing columns would be artificially limited to the range of 4-byte integers. On the other hand this means that you cannot declare a real 4-byte integer auto-incrementing column.</P
106
>Do not forget to use <CODE
108
>dbi_result_get_longlong()</CODE
111
>dbi_result_get_ulonglong</CODE
112
> to retrieve values from columns declared as INTEGER PRIMARY KEY.</P
120
>The (essentially) typeless nature of SQLite has some nasty consequences. The sqlite driver takes great care to reconstruct the type of a field that you request in a query, but this isn't always successful. Some of the functions that SQLite supports work both on numeric and text data. The sqlite driver currently cannot deduce the field type correctly as it would have to check all arguments of each function. Instead the sqlite driver makes a few assumptions that may be right or wrong in a given case. The affected functions are <CODE
122
>coalesce(X,Y,...)</CODE
136
>The sqlite driver currently assumes that the directory separator of your filesystem is a slash (/). This may be wrong on your particular system. It is not a problem for Windows systems as long as the sqlite driver is built with the Cygwin tools (see <TT
143
>Listing tables with the <CODE
145
>dbi_conn_get_table_list()</CODE
146
> libdbi function currently returns only permanent tables. Temporary tables are ignored.</P
150
>The sqlite driver assumes that table and field names do not exceed 128 characters in length, including the trailing \0. I don't know whether SQLite internally has such a limit or not (both MySQL and PostgreSQL have a lower limit). The limit can be increased by changing a single #define in the <TT
157
>In a few cases, the sqlite driver expects you to type SQL keywords in all lowercase or all uppercase, but not mixed. This holds true for the 'from' in a SELECT statement. Type it either as 'from' or as 'FROM', but refrain from using 'fRoM' or other funny mixtures of uppercase and lowercase. Most other database engines treat the keywords as case-insensitive and would accept all variants.</P
166
SUMMARY="Footer navigation table"
195
HREF="copying-fdl.html"
205
>SQLite3 (mis)features</TD
219
>GNU Free Documentation License</TD
b'\\ No newline at end of file'
added
removed
drivers/sqlite3/dbd_sqlite3/x203.html
