-
Notifications
You must be signed in to change notification settings - Fork 478
This page lists Frequently Asked Questions about SOCI project. Feel free to contribute new question or both question and answer by adding a new section below. It is always a good idea to also refer to documentation for details.
SOCI is a database access library written in C++.
Originally developed by Maciej Sobczak as Simple Oracle Call Interface (SOCI), as a C++ friendly alternative to OCI interface in Oracle.
Later, several new database backends have been developed for SOCI, thus the long name has lost its practicality. Currently, if you like, SOCI may stand for Simple Open (Database) Call Interface or something similar.
You can find all available database backends implemented for SOCI in the src/backends directory of the source tree, where each subdirectory is named after a database.
The current list of supported database backends included in officially released of SOCI versions is given in the documentation.
See Users page.
Generally, any fairly recent C++ compilers should be able to compile SOCI sources.
We don't have any means to test SOCI against every compiler in every version available. We do our best to keep SOCI tested with the following compilers:
- GCC 4.x on Linux
- Visual C++ from Visual Studio 2010 and Visual Studio 2012 on Windows.
- clang on OSX and Linux
If anyone has compiled SOCI using MinGW, please feel free to add the details above.
There are no official SOCI binary packages provided to download from SourceForge. Although, maintainers of many Linux distributions and MacPorts for Mac OS X already provide packages.
There is SOCI/soci-pkg repository dedicated to package configurations. Anyone who would like to contribute or maintain SOCI packages can get commit access, so please get in touch.
Integration with Boost C++ Libraries is optional and is not yet enabled in build configurations by default. The integration offers support for variety of Boost data types, for example boost::optional, boost::tuple, boost::fusion.
TODO
TODO
The MySQL 5.6 for Windows installer, by default, installs both 32-bit and 64-bit binaries. So, the files are spread across two locations: 32-bit components in C:\Program Files (x86)\MySQL and 64-bit components in C:\Program Files\MySQL\.
Strangely, only 64-bit binaries of libmysql.{lib|dll} and mysqlclient.lib libraries are installed, in C:\Program Files\MySQL\MySQL Server 5.6\lib. No equivalent binaries for 32-bit platform seems to be provided with the main MySQL installer. (Does the new combined installer of MySQL 5.6.10+ allow to choose between the architectures?)
The 32-bit libraries are provided by separate installer of MySQL Connector/C. Note, the separate installer of the Connector is provided for both, 32-bit and 64-bit architectures, so choose and download the 32-bit version only.
If you use SOCI libraries built for 32-bit architecture, you need to install and configure 32-bit ODBC driver for the database backend you aim to connect with. For 64-bit SOCI, you need 64-bit ODBC drivers.
For example, one may choose to run MySQL 5.6 (64-bit) on Windows 7 or 8 (64-bit) and built SOCI core and ODBC backend binaries using Visual Studio 2010 or 2012 for 32-bit architecture. In order to connect with the MySQL server using SOCI backend for ODBC, it is necessary to install MySQL Connector/ODBC (32-bit) and configure DSN using ODBC Data Source Administrator (32-bit): %windir%\SysWOW64\odbcad32.exe. So, SOCI build and ODBC driver architectures must match.
The Oracle backend uses Oracle Call Interface (OCI). OCI implementation is provided as part of Oracle Database Instant Client package available for number of operating systems for free.
It is worth to check the Instant Client FAQ, especially to understand role of ORACLE_HOME environment variable for the Instant Client.
This is not a SOCI issue in specific, but this is how LOBs work! You may need to read through Oracle documentation on to learn details.
Here is excerpt from Oracle 11g documentation about error code ORA-22920:
The row containing the LOB value must be locked before updating the LOB value.
Follow to chapter on working with LOBS with Locking a Row Containing a LOB section:
To lock a row containing a LOB, specify the
FOR UPDATEclause when you select the row.
Here is ``get_postgresql_version``` function copied from SOCI PostgreSQL tests:
typedef std::pair<int,int> server_version;
server_version get_postgresql_version(soci::session& sql)
{
std::string version;
std::pair<int,int> result;
sql << "select version()", into(version);
if (sscanf(version.c_str(),"PostgreSQL %i.%i", &result.first, &result.second) < 2)
{
throw std::runtime_error("Failed to retrieve PostgreSQL version number");
}
return result;
}
It makes it very easy to check the version:
soci::session sql(backEnd, connectString);
server_version version = get_postgresql_version(sql);
if (version >= server_version(9,2))
{
// PostgreSQL 9.2 detected
}
TODO