Welcome to SQLiteWrappers, a set of C++ classes to encapsulate SQLite v3. The code below shows a simple example to open a database and add a row to a
table called "tblTest" with one text column (without any error handling!):
db.Exec("INSERT INTO tblTest VALUES ('sample
Here's a further example to run a simple parameterized query to do an INSERT
on the previously mentioned "tblTest":
stmt.Prepare16v2(db, L"INSERT INTO tblTest VALUES(?);");
char* szData = "More
The classes provided are as follows:
- CDB which represents a database, or in other words sqlite3*
- CValue which represents a value stored in a database, or in
other words sqlite3_value* pointer.
- CStatement which represents a statement, or in other
words a sqlite3_stmt* pointer.
- CValue2 which represents a combined CValue and CStatement
(useful when you want to have a CValue instance with the same lifetime as a
- CBlob which represents a blob in SQLite or in other words a
- CPtr which encapsulates something which needs to be freed using
sqlite3_free as well as printf style formatting of SQL Strings using
- CRowset provides an STL compliant encapsulation of a rowset as
returned from SQLite3::CStatment::ExecRowset.
- CRowset2 which represents a combined CRowset and CStatement
(useful when you want to have a CRowset instance with the same lifetime as a
CStatement e.g. SQLite3::CDB::ExecRowset).
- CRowset::iterator which is of type SQLite3::CRowsetIterator
which provides an STL compliant input iterator to iterate across the
contents of SQLite3::CRowset.
- CRow represents an individual row of a rowset as provided by
- CRow::iterator which provides a STL random access iterator to iterate across the columns of a CRow.
- A complete wrapper for all of SQLite v3 functionality.
- Hides the complexity of sqlite3 printf functionality.
- Automatic and optional resource de-allocation of all SQLite resource
types in C++ destructors
- Classes have no external dependencies on other libraries such as ATL or
- Provides a thin veneer over the SQLite3 C API so you should be able to
easily map your existing C style SQLite code to C++ without many changes.
All errors are still indicated using return values from methods as opposed
to using exceptions. Another reason this approach makes sense is that it is
difficult to distinguish between some return values from SQLite, e.g. not
all return values from sqlite3_step are errors but indicate conditions which
client code may need to react to e.g. SQLITE_ROW or SQLITE_DONE.
- Provides STL iterator access to the returned rowset. The class returned
from CStatement::ExecRowset is SQLite3::CRowset which provides an input STL
iterator to traverse though all the rows returned by
SQLite3::CStatement::Step. Each row as returned from the CRowset iterator is
represented by a SQLite3::CRow. Finally SQLite3::CRow provides a random
access STL iterator to all the columns returning a SQLite3::CValue. This
allows you to write code which iterates across all rows and columns as
FROM tblTest", rowset);
for (SQLite3::CRowsetIterator iter =
rowset.begin(); iter < rowset.end(); iter++)
row = *iter;
for (SQLite3::CRow::iterator iter2 = row.begin();
iter2 < row.end(); iter2++)
SQLite3::CValue& column = *iter2;
- Provides validation of SQLite resource pointers in all method calls.
- Provides ExecScalar methods in the CDB class modelled on the same
method name as provided by the CppSQLite C++ classes on CodeProject at
Unlike the code there, my version of ExecScalar will handle any data type
through the use of the CValue2 class. This allows you to write the following
(without any error handling!) which returns the number of rows (as a 64 bit
quantity) in a table called "tblTest":
db.Exec16Scalar(L"SELECT COUNT(*) FROM tblTest", rowCount);
number of rows in tblTest is %I64d\n", rowCount.Int64());
zip file contains the
SQLiteWrappers source code and a simple VC 2010 console based application which
demonstrates most of the classes functionality.
- You are allowed to include the source code in
any product (commercial, shareware, freeware or otherwise) when your product
is released in binary form.
- You are allowed to modify the source code in
any way you want except you cannot modify the copyright details at the top
of each module.
- If you want to distribute source code with
your application, then you are only allowed to distribute versions released
by the author. This is to maintain a single distribution point for the
V1.0 (13 June 2012)
V1.01 (28 June 2012)
- CValue methods have been made const where appropriate
- CStatement methods have been made const where appropriate
- Implemented a CStatement::ExecRowset method which provides STL iterator
accessor to the returned rowset. The class returned from ExecRowset is
SQLite3::CRowset which providess an input STL iterator to traverse though
all the rows returned by SQLite3::CStatement::Step. Each row as returned
from the CRowset iterator is represented by a SQLite3::CRow. Finally
SQLite3::CRow provides a random access STL iterator to all the columns
returning a SQLite3::CValue
- Two additional methods called SQLite3::CDB::ExecRowset and
SQLite3::CDB::ExecRowset16 are provided which encapsulate
SQLite3::CStatement::ExecRowset which do not require any parameter binding.
The output parameter from these two methods is a SQLite3::CRowset2 which
contains an SQLite3::CStatement as a member variable.
- Addition of a "SQLITE3WRAPPERS_LOCAL_INCLUSION" pre-processor define
which if set will cause SQLite3 to be pulled in via a #include "SQLite3.h"
instead of via #include <SQLite3.h>. This allows SQLiteWrappers to be
included in projects which statically compile to SQLite3 from the same
directory as your application code.
V1.02 (7 July 2012)
- const and const_reverse iterators have been added to CRow class.
- CRow column iterators now support std::distance
- Fixed a number of /analyze compiler warnings
- Classes now support a SQLITE3WRAPPERS_WCHAR_T_SUPPORT preprocessor
define which treats all UTF16 strings as wchar_t* instead of void*. This can
help avoid client code needing to do casts where it has a wchar_t data type
defined. It also can help find errors where you pass UTF8 or narrow strings
to a method which requires a UTF16 string. These checks can be made more
useful if you are using the /Zc:wchar_t VC compiler setting.
- CStatement::Bind and Bind16 methods which take UTF8 and UTF16 strings
now use a default value for the length parameter
V1.03 (21 July 2012)
- SQLITE3WRAPPERS_WCHAR_T_SUPPORT preprocessor value has been removed and
been replaced with the opposite which is SQLITE3WRAPPERS_NO_WCHAR_T_SUPPORT.
By default the classes will now support wchar_t string values unless the new
SQLITE3WRAPPERS_NO_WCHAR_T_SUPPORT is defined.
- Removed unnecessary reinterpret_cast's from the sample app.
V1.04 (23 February 2013)
- Updated copyright details.
- Added support to the CStatement::Bind* methods to support binding
by named parameter. Thanks to "Prepost" for suggesting this nice addition.
V1.05 (25 March 2016)
- Updated copyright details.
- Updated the code to clean compile in VC 2013 & VC 2015
- Addition of a "SQLITE3WRAPPERS_WIN32_INCLUSION" pre-processor define
which if set will cause SQLite3 to be pulled in via a #include
<winsqlite\winsqlite3.h>. This allows SQLiteWrappers to be compiled against
the Windows 10 DLL version of SQLite. Please note that to use this you must
use the Windows 10.0.10586.0 SDK. Note that even when you do this you will
probably get import errors trying to link your code. This is because the
version of SQLite included in Windows 10 is 18.104.22.168 and the winsqlite3.h
header file included in the Windows SDK does not have the correct defines in
it to allow you to specify the __stdcall calling convention when linking to
the DLL. You can change the calling convention on the translation unit which
includes SQLiteWrappers.h in your application by using the __stdcall (/Gz)
compiler setting and then your code should link properly. A checkin was done
in March 2015 to the SQLite codebase which addresses this and you should
expect to see this fix in the next release of the Windows 10 SDK. For the
moment because of this issue, it is still easiest to just add the SQLite
amalgamation files to your Visual Studio project to pull in support for
- Updated the code to compile against SQLite 3.11.1. Added support
for sqlite3_close_v2, sqlite3_malloc64, sqlite3_realloc64,
sqlite3_bind_blob64, sqlite3_bind_text64, sqlite3_bind_zeroblob64,
sqlite3_value_subtype, sqlite3_value_dup, sqlite3_value_free,
sqlite3_db_cacheflush, sqlite3_snapshot_get & sqlite3_snapshot_open
V1.06 (18 March 2017)
- Updated copyright details.
- Updated the code to compile against SQLite 3.17.0. Added support for
sqlite3_expanded_sql, sqlite3_trace_v2, sqlite3_set_authorizer &
- Updated the code to clean compile in VC 2017.
- Removed support for the deprecated APIs: sqlite3_trace &
- Replaced NULL with nullptr throughout the code. This does mean that
VC 2010 is now the minimum compiler required.