Probably you forgot to include sqlapi.lib (or other SQLAPI++ library, depends on the compiler and/or static/dynamic version) into the project. To link with SQLAPI++ library you have to include sqlapi.lib into you project (as well as *.cpp)

For example, in Visual C++ you have to do the following:

1. In workspace tree select the project that you link with SQLAPI++
2. Use "Add Files to Project..." command on the right click menu and add sqlapi.lib to you project
3. Press F7 button to compile and link you project

• sqlapi.lib should be used when linking with dynamic version of SQLAPI++ using Microsoft Visual C++
• sqlapis.lib to link with a static version using MSVC++
• sqlapib.lib to link with a dynamic version using Borland C++ compiler
• sqlapibs.lib to link with a static version using Borland C++ compiler
• sqlapibb.lib to link with a dynamic version using Borland C++ Builder compiler
• sqlapibbs.lib to link with a static version using Borland C++ Builder compiler
• To link with a debug version use appropriate lib file that ends with 'd'

SQLAPI++ library automatically creates SAParam object to represent procedure status return code.

After a command execution you can check it value. This SAParam object's name is "RETURN_VALUE", object's type is SA_dtLong, object's direction type is SA_ParamReturn.

Sybase ASE server does not provide information about parameter's direction type, that's why SQLAPI++ library defines all parameters (except status result code) as input (SA_ParamInput). If you have input-output parameters in the procedure you have to call SAParam::setParamDirType method for these parameters before command execution and set parameter's direction type explicitly (SA_ParamInputOutput).

You shouldn't call this method for procedure status result code because it is detected correctly (as SA_ParamReturn) by the library.

There is no need to call this method for Sybase ASA because all parameters are detected correctly automatically (including the direction type).

SQLAPI++ has to set the version of Client-Library behavior when it connects to Sybase. By default SQLAPI++ tries to set 12.5 behavior; if it fails, SQLAPI++ tries to set 11.0 behavior and so on from the highest version to the lowest one until it succeeds. Finally the connection is successful, but every time when it fails Sybase server generates the appropriate error message and adds the same error message to the "sybinit.err" file.

The solution is to set the CS_VERSION option to "Detect" using SAConnection::setOption method. In that case SQLAPI++ automatically detects the maximum available version of behavior via the version of Client-Library.

We provide SQLAPI++ binaries that are linked with Microsoft Visual Studio 6. Visual C++ 2005 compiler turns the /Zc:wchar_t option on by default. This is incompatible with Visual C++ 6.

To avoid this problem you can turn off /Zc:wchar_t option (use /Zc:wchar_t- or look at the project options dialog ('Treat wchar_t as Build-in Type' item).

But the best option is to rebuild SQLAPI++ with Visual C++ 2005 compiler.

There is an SQL Server ODBC/SQLNCLI Driver for Linux that provides native connectivity from Linux to Microsoft SQL Server.

SQLAPI++ support this client software but Microsoft releases this driver only for x86-64 Linux platforms. When you want to run the software on 32-bit Linux or any other Unix-like system you must use ODBC connection. You need ODBC driver manager (most known are iODBC or unixODBC) and MSSQL ODBC driver (FreeTDS ODBC driver or commercial EasySOFT one).

You must install and configure ODBC software. Often Linux distribution maintainers split the software into several packages, for example Debian Lenny includes the next iODBC and FreeTDS packages:

• iodbc - GTK+ config frontend for the iODBC Driver Manager
• libiodbc2-dev - iODBC Driver Manager (development files)
• libiodbc2 - iODBC Driver Manager
• freetds-common - configuration files for FreeTDS SQL client libraries
• freetds-dev- MS SQL and Sybase client library (static libs and headers)
• libct4 - libraries for connecting to MS SQL and Sybase SQL servers
• libsybdb5 - libraries for connecting to MS SQL and Sybase SQL servers
• tdsodbc - ODBC driver for connecting to MS SQL and Sybase SQL servers

It's enough to have installed only iodbc, libiodbc2, freetds-common and tdsodbc packages. For the first time it's better to configure and test DSN (any driver manager includes console tool for command line SQL):

bedlam:~# cat ~/.odbc.ini
[ODBC Data Sources]
MSSQL = FreeTDS driver
[MSSQL]
Driver = /usr/lib/odbc/libtdsodbc.so
Server = BEDLAM-M\SQLEXP2008EN
Database = pubs
TDS_Version = 7.0

bedlam:~# cat ~/.odbcinst.ini
[ODBC Drivers]
FreeTDS driver = Installed
[FreeTDS driver]
Driver = /usr/lib/odbc/libtdsodbc.so
Setup = /usr/lib/odbc/libtdsS.so

iodbc package provides iodbctest tool I run with parameters to check the ODBC DSN status:

bedlam-home:~# iodbctest "DSN=MSSQL;UID=sa;PWD=xxx"
iODBC Demonstration program
This program shows an interactive SQL processor
Driver Manager: 03.52.0607.1008
Driver: 0.82 (libtdsodbc.so)

SQL>

Then you can connect using SQLAPI++:

con.Connect("MSSQL", "sa", "xxx", SA_ODBC_Client);

or without DSN configured:

conn.Connect("DRIVER={FreeTDS driver};SERVER=BEDLAM-M\SQLEXP2008EN;DATABASE=pubs;TDS_Version=7.0", "sa", "xxx", SA_ODBC_Client);

You need a GNU patch tool. Version for Win32 can be downloaded from SouceForge. Then run it from the console like:

SQLAPI++ uses libdl library API to load DBMS API. So you should include this library when you linking your binary file with SQLAPI, e.g.:

g++ -I../inclide -L../lib step1.cpp -o step1.out -lsqlapi -ldl

or with static SQLAPI without libpath:

g++ -I../inclide step1.cpp -o step1.out ../lib/libsqlapi.a -lsqlapi -ldl

Default MySQL API doesn't allow to have several opened result set per connection. This is exactly what mysql_use_result does. The connection is blocked until you fetch all result set rows. When you'd like to run another command when there is not fetched result set at the same connection you must use another solution. The simplest - using MySQL 'store' result set:

SACommand cmd(&con, "select ...");
cmd.setOption("HandleResult") = "store";
cmd.Execute();
...

Then SQLAPI uses mysql_store_result and all rows cached at he client side after query is executed and you can fetch the result and execute another command at the same connection. The not good thing - this solution uses local MySQL client data cache. So MySQL guys added another feature - statement API. statement API allows to execute command but the result set stored at the client side. SQLAPI++ can use this feature with 'SELECT' commands. The limitation - the single, forward-only result set only:

SACommand cmd(&con, "select ...");
cmd.setOption("UseStatement") = "TRUE";
cmd.Execute();
...

"I have 1 SAConnection object and 2 SACommand objects. One of the SACommand objects is simply stepping through the records in a table. The second object is attempting to INSERT a new record into the same table, before we have processed all of the records in the first command.
Is this not allowed or am I doing something wrong?"

This is known SQL Server issue. SQL Server doesn't allow to have the several result sets at the same connection by default (the same problem is actual also for Sybase ASE, MySQL, ...). The possible solutions for SQL Server:

• using MARS_Connection option. This is global option for the connection. You can turn it on like:
  SAConnection con;
con.Connect(_TSA("bedlam-m\\sql2014en@test;MARS_Connection=yes"), _TSA(""),
_TSA(""), SA_SQLServer_Client);
• using the server side cursor for executing SACommand:
  SACommand cmd(&con, _TSA("select ..."));
cmd.setOption(_TSA("SQL_ATTR_CURSOR_TYPE")) = _TSA("SQL_CURSOR_DYNAMIC");

See below the simplified usage scenario:

while(....)
    {
        try
        {
            if(!con.isConnected())
                con.Connect(...);
            // database operations below
            ...
        }
        catch(SAException& x)
        {
            if(con.isConnected())
            {
                if(!con.isAlive())
                {
                    try {
                        con.Disconnect();
                    } catch(SAException&) {
                        con.Destroy();
                    }
                }
            }
        }
    }