This allows to confirm that tcp_user_timeout parameter works correctly
for PostgreSQL connections, as specifying different values for it
results in different elapsed time before the query fails.
Use "_s" versions of the standard C functions if possible/simple to do
and disable deprecation warnings explicitly in a couple of places where
this could not be done instead of disabling them globally.
Also stop using strcpy() entirely and use strncpy() instead.
See #1268.
The compiler somehow gives a warning about the loop line in this test
being unreachable, even though it clearly is.
Restructure the code to avoid returning from the loop to avoid it.
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.
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.
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.
Use these functions instead of directly using SQLite3 ones in the test.
This makes no real difference, but allows to provide the implementation
of these functions in SOCI SQLite3 backend itself and so works even when
SQLite3 library is linked statically into this backend and is not linked
into the test.
Since SQLite doesn't have a type system, we have to always be prepared
to select huge numbers, even if the "type" is e.g. int8.
To do that, we overwrite the exchange type (e.g. in row based APIs) to
always be (u)int64 for integers to avoid over-/underflows.
Update the documentation to explain this SQLite peculiarity and add a
test verifying that this behaves as expected.
Fixes#1190.
Closes#1217.
Check that the values of the vectors elements that resulted in the error
appear in the output too, at least for the backends that have been
already updated to do it (i.e. none yet, but some of them will be soon).
Check for the exact fragment expected and not just a single word.
Also use REQUIRE_THAT() instead of CAPTURE() + CHECK() combination, this
is simpler and provides the same information (arguably more clearly).
Check that a partial update does throw an exception instead of checking
that it may throw it and check that get_affected_rows() returns the
actual number of affected rows instead of returning something non zero.
The only remaining exclusion is the PostgreSQL ODBC driver which just
seems to be buggy, notably in its versions < 13.02 when it inserted
valid rows into the database but still returned fatal error (with later
versions it doesn't insert anything, which is inconsistent with the
other drivers and unhelpful, but not quite as bad).
The unit test relies on failing to insert "a" into an integer column but
SQLite is perfectly fine with doing this by default, so use an explicit
CHECK constraint to prevent this from succeeding and to make it behave
in the same way as the other databases.
"Suitable" means that the soci::is_contiguous_resizable_container is
specialized to have true "value" member. This specialization is provided
for std::string and std::vector<T> where sizeof(T) == sizeof(char).
This restores compatibility with the existing code and allows to read
BLOB data into a string again.
Fixes#1173.
Closes#1189.
Work around vector int8_t unit test failure with FreeTDS: due to a bug
in the current versions of FreeTDS ODBC drivers, negative TINYINT values
are stored as positive values in the database and so sorting by them
doesn't work, even if reading them back does work.
The issue (https://github.com/FreeTDS/freetds/issues/627) was fixed in
the latest FreeTDS version, but for now work around it in SOCI tests to
let them pass even with older ones.
See #1194.
SQLite documentation states that it can change in the future and it's
simple enough to turn it off explicitly, so do it.
Also combine 2 very similar tests in a single one and use 2 sections for
them instead.
No real changes.
Negative values saved to the database are stored as positive numbers in
at least some versions of the database, so even if they're converted
back to the negative ones when we read them back, ordering the result
set by them doesn't work as expected, see #1193.
Until this can be fixed, work around this by sorting the values in the
test itself instead.
