Tzu-Chien Chiu uttered:
OK. But what I don't understand is: is this (lack of sqlite3_exec16) by
design?
The sqlite3_exec function is a deprecated interface used by earlier SQLite
releases. New applications should use, for performance reasons if nothing
else, sqlite3_compile/sqlite3_step/sqlite3_finalize or related 16 bit
equivalents.
I presume sqlite3_exec16 was not written because new applications would
not be written using the interface. There have been no calls for such an
interface until now, and so it was obviously low in demand. Existing
applications ported from v2 to v3 use just the UTF-8 interface only as
that better maps to the v2 interface.
Yet another question on the library design. I've seen some projects
which provide a same interface for all supported encodings, e.g.
#ifdef _UNICODE
#define sqlite3_open sqlite3_open_utf16
#else
#define sqlite3_open sqlite3_open_ansi
#endif
#ifdef _UNICODE
#define strcpy _strcpy_w
#else
#define strcpy _strcpy_a
#endif
I'd like to know the design rationales on why sqlite chose to make
available the interfaces with different encodings simultaneously, and
have the users _explicit_ choose which to use.
Data migration, perhaps? Or the developer would prefer to use UTF-8
enoding but use the UNICODE wide version of the Windows APIs?
2006/7/10, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
"Tzu-Chien Chiu" <[EMAIL PROTECTED]> wrote:
>
> Is it true: the only way the fetch the values of the fields in UTF-16
> is to write another version of sqlite3_exec() wrapping sqlite3_*16()
> functions?
>
You do not have to write a new sqlite3_exec16() from scratch.
You can make a copy of sqlite3_exec() and with a few simple
edits turn it into sqlite3_exec16().
--
D. Richard Hipp <[EMAIL PROTECTED]>
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
