While there is no exact equivalent to this new database type among the
old dt_xxx constants, we still shouldn't throw from this function as
it's called from statement_impl::describe(), notably used by rowset API,
and throwing an exception from there prevented rowset from being used at
all with the NVARCHAR() columns mapped to db_wstring.
This was lost during CMake rewrite, but it makes sense to keep doing it,
as it's a common convention under Windows due to the absence of
SOVERSION equivalent, and it broke dynamic backend loading by name.
Fix this by moving ABI_VERSION definition to the main CMakefile and also
defining ABI_SUFFIX there, if necessary, which is appended to the names
of all libraries, if it is defined.
See #1248.
Get rid of a separate soci_sqlite3_builtin target as it didn't work
correctly when using static libraries.
Instead, just compile the amalgamated SQLite3 source as part of
soci_sqlite3 itself, which works after the changes of the parent commit
as we don't get tons of warnings for this C file any longer.
This results in an extra "GLOB verification" step when building and just
doesn't seem worth it, especially as we already list all the source
files and backend-specific headers explicitly.
This also fixes an annoying "GLOB mismatch" error which happened when
using Vim as its swap files (".foo.h.swp") were wrongly matched by the
GLOB wildcard and so switching to another file in Vim changed the GLOB
expansion.
This doesn't work when using C++20 as they produce values of "char8_t*"
type which is different from the expected "char*".
Just assume UTF-8 encoding is always used, we already use /utf-8 flag
for MSVC and all Unix compilers should use it too anyhow.
Recognize permission and constraint violation errors as well as a few
other ones that haven't been actually observed but seem to match well
the existing error categories.
512 characters might, conceivably, be too small for the error messages
including several database object names if they are long enough, so
increase it to 4096 which should really be enough.
Improve error reporting for ODBC, PostgreSQL and SQLite backends, in
particular, provide, or improve, get_error_category() in the exception
classes of all these backends.
See #1235, #1236, #1237.
In particular, detect error codes corresponding to "no_privilege", as
they may need to be handled differently from the other errors at the
application level.
No real changes, just make this backend more consistent with the other
ones, which already have their own error.cpp files, and reduce physical
dependencies.
Don't precompute it in the ctor, it seems better to do it only when it's
really needed: the code doing it can't throw, so it's safe, and we might
not need to run it at all.
No real changes.
Try to classify all the possible SQLite result codes using SOCI
error_category enum.
In particular, this allows to detect connection and permission errors.
Update the unit test to test the error category too.
Don't use CHECK_THROWS_WITH(), it's convenient but not very flexible,
while an explicit try/catch will allow us to add more checks on the
exception object in the upcoming commits.
Call sqlite3_errmsg() directly in sqlite3_soci_error ctor instead of
doing it in multiple places in the backend code.
Throw soci_error when there is no SQLite3-specific information
associated with the error.
Update the documentation to make it more clear that both
sqlite3_soci_error and soci_error must be caught.
Don't use internal function names in them, they shouldn't be shown to
the users and don't mean much anyhow, so either rephrase the error or
just omit the extra noise from it, as in the most common case when
executing a statement failed.
