Such dialogs can be unexpected and confusing, as reconnection can happen
automatically, and not in a response to a user action.
Implement this by adding a new "reconnect" option and add is_option_on()
helper to connection_parameters to facilitate using it.
Try to return something meaningful from get_error_category() for a few
SQLSTATE values that seem to be reasonable standard and map well to the
existing error_category enum values.
This is far from being exhaustive, but is still better than nothing and
allows "Reconnect" unit test to pass when using MS SQL ODBC driver.
This function can be used to check if the connection to the server is
still available (and then, perhaps, call reconnect(), if it isn't).
Implement it for all backends using native API (except for SQLite for
which it always returns true).
If the failover callback doesn't provide the connection string to use,
default to the originally used one instead of using empty connection
string which is almost certainly not what we want.
Note that this requires storing the original connection parameters in
postgresql_session_backend, as we don't have access to the ones stored
in the session object and it seems wrong to add backlinks from the
backend to the session object.
Closes#793.
When working directly with concrete statement_backend classes, their
alloc() and clean_up() methods must be called directly, which suffers
from all the usual problems, especially in presence of exceptions.
Avoid them by using the new auto_statement class which takes care of
calling these methods in its ctor/dtor instead.
An alternative could be to make the concrete classes themselves use
RAII, but this would be more error prone (e.g. there would be a risk of
alloc() being called twice) and require many more changes, so, at least
for now, use this more lightweight solution.
No real changes.
Add another C++11-like macro (similar to SOCI_OVERRIDE) which can also
be used in C++98 code.
The main advantage is that new code can now use SOCI_NOEXCEPT instead of
the old "throw()" and it will be possible to simply replace it with
"noexcept" after dropping C++98 support.
Generalize the use of strtoll() instead of sscanf() for the conversion
to unsigned integer types too and extend the code doing it to a couple
of new simple reusable functions that can now be used in all backends.
Keep PostgreSQL idiosyncratic conversion of "f" and "t" to integers to
avoid changing the existing behaviour, even if it's not really clear
whether this is needed for all types.
Remove apparently unused conversion_use_type::convert_from_base() which
prevents this class from being used with const references.
Closes https://github.com/SOCI/soci/pull/797
Using SQL_SS_LENGTH_UNLIMITED for size seems to only work with SQL
Native Client ODBC drivers v11+, but not with the old, but still used,
SQL Server ODBC driver, while just using SQL_LONGVARCHAR works with both
of them and is even simpler.
Really closes#383.
* Add explicit option for generating ODBC DB2 tests
- can be activated by -DWITH_ODBC_TEST_DB2
- needs proper connect string via -DSOCI_ODBC_TEST_DB2_CONNSTR
* Add DB2 as database product for ODBC
* Add support for not ODBC spec compliant ODBC driver
IBM DB2 driver is not compliant to ODBC spec for indicators in 64bit
SQLLEN is still defined 32bit (int) but spec requires 64bit (long)
* Disable GCC warning as error for -Wstrict-aliasing
The casts are necessary to handle not compliant drivers in 64bit.
* Rename noncompliant helper methods
No big changes yet, but it is now possible to use a custom logger object which
may do something else than just write the query string passed to it to a
stream.
The old behaviour is preserved by using the standard SOCI logger by default
which does write the query to the stream.
MSVC++ 1900+ always compile with C++11 mode enabled, so it should be
safe to selectively enable 'override'specifier for internal use.
It does not enable all C++11 features for SOCI and we still compile
with C++11 compilation mode SOCI_CXX_C11=OFF by default.
Refactoring performed with clang-tidy-4.0:
cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=ON -DSOCI_CXX_C11=ON ..
run-clang-tidy.py -clang-tidy-binary -header-filter='.*' \
-checks='-*,modernize-use-modernize' -fix
Fix compilation issues for Visual C++ 8.0 (VS2005)
* Add _WIN32_WINNT minimal required version to soci-platform.h to fix windows.h issue related to use of Add/RemoveVectoredExceptionHandler.
* Override SECTION macro since default macro parameter (3 required / 2 given or 2 required / 1 given) do not expand and lead to syntax error.
There is no reason to not have them and this allows to write slightly
shorter and safer code using exchange_type_cast<> instead of "raw"
static_cast<>.
There is no real XML support in Firebird, so handle it in the same way
as CLOB -- this is the best that can be done with this database anyhow
and is much better than not supporting it at all.
Reuse the existing BLOB support, however we now need to allocate a BLOB
inside firebird_standard_use_type_backend objects as, unlike when using
soci::blob objects, we don't have any way to associate backend-specific
data with the parameter otherwise.
This difference between CLOB and BLOB support is not ideal, but there
doesn't seem to be any way to avoid it.
This is mostly done in order to allow SOCI headers to compile cleanly
with -Woverloaded-virtual (or corresponding MSVC warning C4266) in
effect, but it also allows to turn the same warning on for building SOCI
itself, which can be useful.
Closes#573.
SQLite, MySQL and PostgreSQL backends used the same but slightly
different code for parsing the contents of a buffer into std::tm struct.
Replace all these different versions with a single version, copied from
the PostgreSQL variant, which seems like the most complete, in the
common code.
Update MySQL-specific test to not expect parsing a string containing
time without date to yield year 2000, this didn't make any sense at all
and PostgreSQL default of year 1900 makes at least slightly more sense.
These functions are helpful to allow writing queries not using any
tables portably, i.e. they basically abstract the difference between
"select ... from dual" in Oracle and just "select ..." in almost all the
other backends.
This was done for most, but not all, of them.
Add missing checks to ensure consistent and safer (exception instead of
a null pointer dereference) behaviour in all cases.
