wxWidgets Discussion Forum

wxSQLite3 is a C++ wrapper around the public domain SQLite 3.x database and is specifically designed for use in programs based on the wxWidgetslibrary. wxSQLite3 has been tested with Unicode builds of wxWidgets on wxMSW, but should be usable on other builds and platforms as well (feedback welcome). wxSQLite3 is a component of wxCode and can be downloaded from there.

wxSQLite3 does not try to hide the underlying database, in contrary almost all special features of the current SQLite3 version 3.2.2 are supported, like for example the creation of user defined scalar or aggregate functions. Since SQLite stores strings in UTF-8 encoding, the wxSQLite3 methods provide automatic conversion between wxStrings and UTF-8 strings.

Under what license is this code?

RealityMage wrote:Under what license is this code?

Under the wxWidgets aka wxWindows license.

Regards,
Ulrich

Very useful, thanks.

Hi!
It's indeed a very usefull class (modeled after CppSQLite3, right?).

One thing that could be added IHMO is handling SQLITE_SCHEMA errors. I use a sqlite db that is accessed by more then one application at the same time. This works perfectly fine, but will sometimes result in a SQLITE_SCHEMA error for queries if one app modified the db and the other is trying to access it. The slqite faq says that the "standard" way of handling this is to simply retry the query. In fact it works, the first query fails, the second succeeds. Currently I'm handling wxSQLite3Exexception and check for SCHEMA errors, then retry the query. Maybe this you be added to the lib, so that it automaticaly retries instead of throwing the exeception. Just a thought...

upCASE wrote:It's indeed a very usefull class (modeled after CppSQLite3, right?).

wxSQLite3 was inspired by three different C++ wrappers for SQLite: wxSQLite (which supports only SQLite 2.x), CppSQLite3 (which is not wxWidgets specific, i.e. no wxWidgets Unicode support), and the wxCode component databaselayer (which hides the underlying database and therefore does not support SQLite specific functionality. Additionally it doesn't support wxWidgets Unicode either).

upCASE wrote:One thing that could be added IHMO is handling SQLITE_SCHEMA errors. I use a sqlite db that is accessed by more then one application at the same time. This works perfectly fine, but will sometimes result in a SQLITE_SCHEMA error for queries if one app modified the db and the other is trying to access it. The slqite faq says that the "standard" way of handling this is to simply retry the query. In fact it works, the first query fails, the second succeeds. Currently I'm handling wxSQLite3Exexception and check for SCHEMA errors, then retry the query. Maybe this you be added to the lib, so that it automaticaly retries instead of throwing the exeception. Just a thought...

When I created wxSQLite3 I thought about handling SCHEMA errors, but decided against it, since handling SCHEMA errors is not at all trivial. For example which reaction is appropriate depends on the kind of the SQL statement:

For INSERT, UPDATE or DELETE a simple retry might be a good choice. But how often should the retry take place? The SQLite FAQ code example contains an endless loop! I don't want to introduce such kind of code into wxSQLite3.

In case of a SELECT statement the situation is still more complex. The SCHEMA error could happen after reading several result rows. If wxSQLite3 would then redo the query automatically it would start from scratch delivering the already read rows again. If your application code gathers the result set in an array for example you would get duplicate rows.

When retrying a query another problem arises if the SQL statement contains bind variables. You would have to rebind the variables. If wxSQLite3 should handle this automatically this would induce a lot of extra house keeping.

Therefore I think to handle SCHEMA errors in an appropriate way is easier for the application developer than for wxSQLite3.

Regards,

Ulrich

wxSQLite3 version 1.1 incorporates now the newest SQLite version 3.2.7. Additionally there is now a configure script for Unix builds, but support for wxWidgets Unix builds is still weak due to insufficiencies in the wxCode bakefiles. Therefore wxSQLite3 officially supports still only wxMSW, although it has been used successfully with wxGTK.

Regards,

Ulrich

Hi,

wxSQLite3Table::GetAsString(const wxString columnName) seems that does not work. The internal use of the function wxSQLite3Table::FindColumnIndex seems that returns the total number of columns instead of the column index.

Thanks.

Ps. Sorry for my poor english.

lrm wrote:wxSQLite3Table::GetAsString(const wxString columnName) seems that does not work. The internal use of the function wxSQLite3Table::FindColumnIndex seems that returns the total number of columns instead of the column index.

You are right: wxSQLite3Table::FindColumnIndex returned the wrong index. I corrected the code and made a new file release.

The current wxSQLite3 version is now 1.2.

Thank you for reporting the bug.

Regards,

Ulrich

Hi Ulrich,

It seems that there is a problem in the function wxSQLite3ResultSet::GetInt64(int columnIndex, wxLongLong nullValue), returns an incorrect value.

In another matter, there is possibility to add GetInt64 functions to the class wxSQLite3Table?

Thanks


Ps. Sorry for my poor english.

lrm wrote:It seems that there is a problem in the function wxSQLite3ResultSet::GetInt64(int columnIndex, wxLongLong nullValue), returns an incorrect value.

Thank you for reporting this bug. It is now fixed.

lrm wrote:In another matter, there is possibility to add GetInt64 functions to the class wxSQLite3Table?

Sure. This method was missing since the wxString class does not provide a method ToLongLong. I created my own conversion function and added wxSQLite3Table::GetInt64.

The latest release is wxSQLite3 version 1.3.1.

Regards,

Ulrich

Thank you.

Thank you very much.