SAP DB The Open Source Database from SAP AG
SAP AG has transferred its SAP DB database system to an Open Source system. The SAP DB database system has been offered to users of mySAP.com solutions as a free-of-charge alternative to database systems from other vendors since 2000. In accordance with the Roadmap published in October 2000, the source code for the database was made available on schedule at the end of April 2001. Since then, SAP DB can be used by any organization or any person free-of-charge and without restrictions under a GNU General Public License (GPL).
The Open Source initiative for SAP DB does not represent the end of SAP AG developing its own basis technologies. On the contrary: a team of almost 100 developers is working on the further development of SAP DB alone. This is primarily motivated by SAPs efforts to avoid, as far as possible, being dependent on the technologies of other vendors. SAP DB is offered for all mySAP.com solutions as a license cost free equivalent alternative to the systems of other database vendors. In addition, SAP DB is embedded in a number of special application solutions, including mySAP SCM APO (liveCache) and SAP Content Server.
A significant motivation for the Open Source initiative is the price structure for database licenses. This affects not only SAP, but every provider of database-based solutions that must procure database licenses in order to sell them on as part of their own solution, therefore imposing costs on the end licensee. SAP AG hopes to enliven the market through the Open Source initiative and to encourage users to critically examine the high-price policies of the market-leading database providers.
This document provides you with information about the Open Source initiative for SAP DB, the development of the database market from the mid-1990s to the present day, the technological development status of relational databases, and the product positioning of SAP DB.
The Open Source Initiative for SAP DB
Roadmap Implemented With the publication in April 2001 of the source code of the SAP DB database management system (DBMS), SAP AG implemented its intention, announced in October 2000, to transfer its own database system to an Open Source system. The first milestone in the Open Source roadmap was to make available, in autumn 2000, the database kernel and the query and database management tools in the form of executable programs for Windows NT/Windows 2000, Linux (Intel) and common UNIX systems. These programs are available on the SAP DB homepage www.sapdb.org and can be downloaded by any person or organization free of charge. The publication of the source code shortly afterwards represented the next milestone. Since then, any person or organization can view and change the source code of SAP DB and the SAP DB tools.
Made Available under GNU General Public License The SAP DB database kernel is made available under a GNU General Public License (GPL), and the clients and programming interfaces under a GNU Lesser General Public License (LGPL). The GPL license allows developers to modify the programs as they wish, and to distribute the modified programs, as long as this is done by distributing the source code. The most popular Open Source system, the operating system Linux, is also distributed under the GNU GPL. Unlike other well-known Open Source projects, control of the future development of the official SAP DB programs remains with one party; the SAP DB development team at SAP AG.
Users of the SAP DB database system outside the SAP user community receive free online support by e-mail. If desired, these users can take out a Premium Support Contract that guarantees full access to the SAP AG service infrastructure with its well-known high quality.
Efforts for Independence Motivate Development of Own Database The development of the database technology for SAPs own application systems is motivated by SAP AGs efforts to avoid, as far as possible, being dependent on the technologies and products of other vendors. SAPs own database platform therefore primarily provides risk minimization. It is, however, also wise from a commercial perspective. The costs to SAP AG that result from buying database licenses are many times the cost of an in-house DBMS development team.
Against the Oligopolization of the Database Market The cost pressure is increased due to the increasing domination of the database market by a small number of large companies and the high-price policies that result from this. Rising costs for database licenses are driving total license costs for SAP application systems noticeably higher. As the costs of the database licenses are linked to the cost of each SAP application as a percentage of the complete price, and are not discounted, a reduction in price on an SAP application system directly reduces the profit margin. Therefore, high prices for database licenses have a negative influence on the business results of SAP AG.

The distribution of SAP DB free-of-charge is to set a counterpoint to the progressive oligopolization of the database market and the high-price policies of the leading providers. With this Open Source step, SAP confirms its intention to permanently provide its own database system free-of-charge.
Embedded Engine for Special mySAP Applications SAP not only provides its own database system SAP DB as an equivalent alternative to the products of the established database vendors, but also uses it as an embedded engine for special application solutions. An example of this is liveCache, with which you can process large quantities of complex objects very quickly in the main memory. liveCache is a database instance type, that is, a special variant of SAP DB, and an integral part of mySAP Supply Chain Management (Advanced Planner and Optimizer). Another example is the SAP DB Document Server, which forms the technological basis of SAP Content Server and the SAP applications based on it. The SAP DB Document Server is a database instance type that can be used for the management of all types of documents. In both examples, SAP DB is used exclusively. New SAP applications that will run exclusively on SAP DB are currently being developed. SAP AG itself increasingly uses the SAP DB database system for internal database installations.
Open Source Instead of Marketing Despite the increasing breadth of functions of the SAP DB database system, SAP AG does not intend to market the database system commercially, and to enter the DBMS market as a new competitor. Consequently, SAP DB is offered license-free in connection with SAP solutions. The users of mySAP.com applications must simply pay a support and maintenance fee that is determined as a fixed percentage of an accrued license price.
Instead of creating its own distribution channels for its database system, SAP AG decided to make it available free-of-charge through the Open Source initiative. Through this, SAP AG expects to primarily achieve very simple, Internet-based product provision and distribution,
including Internet-based support, and to significantly increase the size of the SAP DB user community. This should contribute to finding any possible errors or performance bottlenecks more quickly, in particular in SAP DB areas that are not used by mySAP.com applications. As SAP DB is positioned as a competitive DBMS that is suitable for all types of databasesupported applications, the specification of SAPs own database development are not restricted to just the specific demands of the mySAP.com solutions.

Due to the high-level of technical complexity of a DBMS, it is less likely that a large number of programmers will make changes to the source code. Nevertheless, a wide user community can help to test the SAP DB database system in application scenarios more comprehensively than SAPs own test structures can.
The Linux community, which naturally has a high affinity to Open Source software, undoubtedly offers the best chance for the creation of a user community outside the SAP customer base. For this reason, SAP DB is part of the professional version of SuSE Linux (as of 7.2). SAP DB is also to be distributed with other versions of Linux in the future.
Competition with Other Open Source Databases There are other Open Source database systems competing with SAP DB in the Linux environment. However, the SAP DB database system clearly distinguishes itself from the other database systems, such as PostgreSQL or mySQL, with regard to performance. SAP DB was designed from the start for use in OLTP applications with a large number of users and transactions. SAP DB is the only Open Source database that can adequately support such a complex and demanding SQL application as the SAP system and ensure round-the-clock operation when doing so. Due to the proven suitability for SAP applications, SAP DB is not only more powerful and more scaleable, but also significantly more robust.
Unlike the providers of the Open Source databases listed above, SAP AG does not depend on recovering its development costs for SAP DB through service income outside the SAP market or through additional products for the DBMS.
The Development of the Database Market since the Mid-1990s A market consolidation has taken place since the mid-1990s, initiated in 1994 with the takeover of ASK/Ingres by Computer Associates, and reaching its highpoint so far in the middle of 2001 with the takeover of Informix by IBM. As Sybase has obviously pulled out of the database business, three big providers dominate the market: Oracle, IBM, and Microsoft. According to an investigation by the Gartner Group, all database vendors together realized 8.8 billion US Dollars worldwide in 2000 and therefore ten percent more than the previous year. Oracle made around a third of this turnover, IBM made just under a third, and Microsoft had a share of around 15 percent. Sybase and Informix had around three percent each. This means that the big three providers now share more than 80 percent of the market.
Market Domination by a Few Large Companies Prevents Price Reduction This oligopoly is one reason that, despite many predictions to the contrary, relational databases have not become a commodity product and there is no sign of an imminent fall in prices. Microsoft has succeeded in delivering a competitive product with SQL Server and has taken the market lead for Microsoft Windows platforms with it. However, as this share is restricted exclusively to Microsoft Windows, it has hardly any influence on the price policies of the market leader Oracle (see Computerwoche No. 16/2001: Oracle lsst sich seine Datenbanken vergolden [Oracles databases turn to gold]).

DBMS Do Not Become Part of Operating Systems The prediction that DBMS would become part of operating systems, often made at the beginning of the 1990s, has proved to be false. On the contrary, the two database products that were developed and marketed by system vendors, Rdb from DEC and Nonstop SQL from Tandem, have become obsolete through being taken over by other vendors. Although the software is still supported, the products no longer appear in the market. Two of the three remaining large database providers are also operating system vendors however, there is no indication that they have plans to integrate these database systems into their respective operating systems.
Status of DBMS Technological Development Relational database management systems (RDBMS) are in the late phase of the Technology Adoption Lifecycle (as in Geoffrey A. Moore: Crossing the Chasm and Inside the Tornado). At the beginning of the 1990s, Michael Stonebraker, then still a Professor at Berkeley, was publicly asking the question, of whether RDBMS were a done deal. In fact, there had only been a small amount of progress made in the last ten years with the exception of attempts to extend the relation model with object-oriented characteristics with regard to the functional performance characteristics. The dominant vendors main interest lay far more in improving the performance, availability, scalability and handling of their database systems. The large providers therefore employed whole panels of specialists at times, in order to be able to continually present new Benchmark records. Nowadays, the interest in benchmarks is significantly reduced. In the meantime, it has become accepted that all database systems relevant to the market have achieved a performance level and a standard of robustness that make them appropriate database systems for business application solutions of (almost) any size. Benchmark tests with databases are nowadays mainly performed by hardware vendors and generally serve to demonstrate the performance capabilities and scalability of new server systems.
The Vision of an Object-Relational Database The functional development of the RDBMS was driven by various visions during the 1990s. In general it had already been decided at the beginning of the decade not to pursue the concept of distributed databases, of which there were originally high expectations, due to the too close linking of database instances connected with it and the lack of application requirements. In the middle of the decade, there was a fear that object-oriented database management systems (OODBMS) might make a triumphal march. Even though the representatives of OODBMS only had a very modest market share, they did put their finger on a supposed weakness of the relational database model that, in concept, is designed exclusively for processing table-type structured, that is, relational information. This type of logical data organization is as unsuitable for processing complex structured or multimedia data as it is well suited to typical business applications. To avoid leaving the field to the representatives of OODBMS without a fight, the concept of object-relational databases was developed. Object-relational database systems were to remove the restrictions of the classic relational model by extending it through object-oriented concepts.

Data Blades Extend the Database Kernel Informix was the leader in this development. Through the take over in 1996 of the startup company Illustra for 400 million dollars, they bought in the Data Blade Technology together
with the services of its originator, the database developer from Postgres, Michael Stonebraker. The Data Blades concept envisioned the extension of the database kernel with additional data types and functions, so that complex data structures could also be stored in the database system, and their data type could correspondingly be used. The idea was quickly picked up by the other big database providers. In this way, IBM extended their DB2 database systems with Extenders. Extenders are preconfigured packages for image and text analysis, the storage of audio and video sequences, and time series analysis. IBM then renamed the DB2 database system to DB2 Universal Database. Finally, Oracle introduced Data Cartridges with Oracle version 8. Object concepts and SQL were interwoven, therefore jeopardizing the robustness of the DBMS, as a programming error in a linked Data Blade, Extender or Data Cartridge endangers the integrity of the database.
Not Accepted by the Market A few years later, it should be noted that the object-relational database concept did not prevail, and there are practically no applications of Data Blades, Extenders or Data Cartridges. An exception to this is a Data Blade that, together with associated functions, implements a data type for geographical coordinates. The term object-relational disappeared at the end of the 1990s, as it was no longer suitable for making a separation between competitors in marketing terms.
OODBMS in a Niche Object-oriented database management systems could not despite the predictions of many analysts establish themselves as a legitimate successor to the RDBMS. They can nowadays only be found in a few areas - such as in the area of CAD/CAE applications or as persistent object stores for Web Application Servers. Relational DBMS will therefore be the predominant database technology for most business applications for at least another decade.
Web Application Servers Displace the Vision of the Universal Database There is another reason for the fact that RDBMS are mainly reduced to their original core functionality nowadays: modern application systems are generally implemented with a three-tier architecture. This includes clients (usually Web clients), Application Servers and a database server. Although the first version of the SAP system involved no Web clients, it was one of the first systems that were based on this three-tier architecture. The introduction of the application server layer had the consequence that the database system was restricted to its most important tasks. Many tasks that had to be taken over by the database server in a two-tier client-server architecture can be better dealt with by the application server. If, in addition, there is a requirement for application portability over different database systems, you cannot use nonstandardized and therefore proprietary functions.

It is the modern Web Application Servers that have contributed to the displacement of the vision of the universal database. The persistent storage of business data will in future be hidden behind Web Services or Data Sources with Internet connectivity, which are integrated and presented uniformly in an application by a Web Application Server. Therefore, the future belongs to the slender SQL database systems, rather than to those overloaded with functions. Functions that are only required in special cases are ballast for normal operation, use unnecessary resources and make the DBMS more complex and therefore more vulnerable.
The Positioning of SAP DB What appeared to be a weakness at the end of the 1990s restraint in the case of topics such as the object-relational concept and deliberately forgoing the battle for yet more functions prove today to be strengths of SAP DB. The SAP DB database system delivers high performance, can be automated to a large degree, is versatile with respect to the types of information that can be processed, meets the current Standards, and provides excellent value in its total operating costs. Modern Architecture for High Performance and Availability Due to its modern architecture, SAP DB provides a high level of performance, scalability and robustness. In this way, the database can fulfill the performance demands of application environments with thousands of concurrent active users and very large data volumes. At the center, the multithread/multi-server architecture ensures a high degree of scalability with sparing handling of server resources. SAP DB fits flexibly into modern server architectures such as multi-processor systems or cluster configurations, and uses the advantages for example, where high availability is concerned without costly configuration. Due to the customizable architecture, SAP DB is suitable as a central database system both for three-tier and two-tier client-server environments.
Effective locking mechanisms, efficient caching of data, intelligent optimization of SQL applications, extensive parallel processing of read and write processes, and strategies to minimize the required write operations are among the architecture characteristics that significantly affect response times and throughput.

SAP DB is designed for interruption-free round-the-clock operation. Required maintenance tasks such as configuration customization, the extension of data or log areas, data backup, the creation of table indexes, and so on, can be performed during production operation without affecting the active users.
High Level of Automation for Unattended Operation As well as performance and robustness of the DBMS, the main focus of the further development of SAP DB is on simpler operation of the database system. The vision of a database system that automatically manages itself to a large degree, and only requires minimal monitoring by the database administrator, is the guideline of the development.
Both the setting up of the database system and the running operation are largely automated. During configuration, SAP DB automatically sets the core parameters in accordance with the existing system environment. During the definition of database objects such as tables and
indexes, the database administrator works exclusively at the level of logical schemas: SAP DB automatically makes the assignment to the physical data structures in mass storage. The database system also handles the growth of tables and indexes completely dynamically. Prior allocation of disk space and regular reorganization runs, that with other databases are tasks that the database administrator must perform, are not required. Due to the dynamic disk space management, interfering interruptions of production operation are not necessary. The database administrator can concentrate on tasks such as user administration or assigning authorizations, and does not need to constantly monitor system resources.
SAP DB is delivered with a package of convenient tools that support the database administrator in performing the few necessary tasks. The most important SAP DB tools are available with a Windows and a Browser interface. In mySAP.com environments, you can additionally incorporate the monitoring of the database system into the monitoring performed with SAP CCMS.
Access to Many Information Types While SAP DB was first optimized as a database system for the SAP system, the application areas now reach far beyond online transaction processing. The data store is no longer restricted to table-type structured information, but now includes both structured and unstructured documents. In this way, SAP DB meets the requirements of the ever more important Internet applications, which mostly use a combination of unstructured data such as HTML pages, images, audio and videos, and increasingly also exchange information with the aid of partly structured documents in the XML format.

Examples of this type of application are the previously mentioned SAP Content Server and mySAP Product Lifecycle Management. An extension to SAP DB conforming to the Web Distributed Authoring and Versioning (WebDAV) standard for the Internet-based storage of documents is in development.
Conforms to Standards SAP DB fulfills the official ISO SQL Standard (ISO-SQL 92, Entry Level), meaning that SQL programs that were created for other database systems can easily be ported to SAP DB. SAP DB offers developers all of the interfaces that could be expected from an open DBMS. For program development, there is a precompiler for C/C++ and interfaces for the Perl, Python, and PHP script languages. Database developers that have previously worked with other systems require practically no (re)training to be able to immediately work with SAP DB.
The standard-compliant ODBC driver allows the use of Windows-based Office or reporting tools. With the help of the JDBC driver, you can easily connect the SAP DB database system to Java-based application servers.
Broad Platform Availability SAP DB is available with the same range of functions for a large number of operating system platforms:
Compaq Tru64 Unix (Alpha) IBM AIX (PowerPC) SUN Solaris (SPARC) HP-UX (HP-PA) Linux (Intel) Siemens Reliant Unix (MIPS) Windows NT/2000 (Intel)
Total Cost of Ownership Represents Incomparably Good Value The total cost of ownership (TCO) for SAP DB is such good value partly because there are no license costs. The total running costs are, however, not determined just by license and maintenance costs, but also strongly influenced by employing and training of operators. Therefore, characteristics such as simple handling and operation without constant monitoring contribute to extremely low total operating costs.

The functionality of the SAP DB ODBC driver is described in more detail for certain areas: Supported Data Types [Page 6] Conversion of SQL and C Data Types [Page 7] Processing SQL Statements [Page 7] ODBC-API Compatibility [Page 8] Unicode Support [Page 20]

Supported Data Types

The ODBC interface differentiates between the data types made available by the database system (SQL data types) and the data types used in the ODBC application (C data types). SQL Data Types [Page 6] C Data Types [Page 6]

SQL Data Types

Every database system defines its own SQL data types. An ODBC driver processes only those data types that are defined by the associated database system. You can use the function SQLGetTypeInfo to determine how an ODBC driver maps the SQL data types of the database system to the ODBC supported data types and to its own driverspecific data types, as well as the specifications for length, decimal places (scale), and the number of valid digits (precision). For more information about the data types defined for the SAP DB database system, see the Reference Manual: SAP DB 7.4, data type [See SAP DB Library] section. SAP DB data types that are supported by the SAP DB ODBC Driver Character Numeric Date Other CHAR, VARCHAR, LONG, CHAR BYTE, VARCHAR BYTE, LONG BYTE DECIMAL, FIXED, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION DATE, TIME, TIMESTAMP BOOLEAN, CHAR EBCDIC, VARCHAR EBCDIC

C Data Types

ODBC C data types represent those data types of C variables in which the application data intended for communication with the database is processed. Relationship Between SQL and C Data Types fCType SQL_C_CHAR SQL_C_SSHORT SQL_C_SLONG SQL_C_USHORT SQL_C_ULONG SQL_C_FLOAT SQL_C_DOUBLE SQL_C_BIGINT ODBC C Typedef SQLCHAR * SQLSMALLINT SQLINTEGER SQLUSMALLINT SQLUINTEGER SQLREAL SQLDOUBLE SQLBIGINT C Type unsigned char * short int long int (32 bit) unsigned short int unsigned long int (32 bit) float double _int64, long (64 bit)
SQL_C_UBIGINT SQL_C_BINARY SQL_C_DATE
SQLUBIGINT SQLCHAR* SQL_DATE_STRUCT
unsigned _int64, unsigned long (64 bit) unsigned char* struct tagDATE_STRUCT { SQLSMALLINT year; SQLSMALLINT month; SQLSMALLINT day;}

SQL_C_TIME

SQL_TIME_STRUCT
struct tagTIME_STRUCT { SQLSMALLINT hour; SQLSMALLINT minute; SQLSMALLINT second;}

SQL_C_TIMESTAMP

SQL_TIMESTAMP_STRUCT
struct tagTIMESTAMP_STRUCT { SQLSMALLINT year; SQLSMALLINT month; SQLSMALLINT day; SQLSMALLINT hour; SQLSMALLINT minute; SQLSMALLINT second; SQLUINTEGER fraction;}

SQL_C_BIT

SQLCHAR

unsigned char

Conversion of SQL and C Data Types
The SAP DB ODBC driver allows the conversion for all supported data types [Page 6]. See also: Microsoft Homepage (http://www.microsoft.com/data/ODBC) in the ODBC Software Development Kit (SDK) under ODBC Programmers Reference, Converting Data from SQL to C Data Types and Converting Data from C to SQL Data Types sections.
Processing SQL Statements
The SAP DB ODBC driver supports the complete ODBC-SQL syntax.
For detailed information about the ODBC function calls, see the Microsoft Homepage (http://www.microsoft.com/data/ODBC) in the ODBC Software Development Kit (SDK) under ODBC Programmers Reference, Chapter 8: SQL Statements, Escape Sequences in ODBC, Scalar Functions section. Numeric functions ABS, ACOS, ASIN, ATAN, ATAN2, CEILING, COS, COT, EXP, FLOOR, LOG, MOD, SIGN, SIN, SQRT, TAN, PI,
SAP AG DEGREES, RADIANS, ROUND String functions System functions Time and date functions
LEFT, SQL_FN_STR_LTRIM, LENGTH, LCASE, REPLACE, RIGHT, RTRIM, SUBSTRING, UCASE, SOUNDEX USERNAME, DBNAME, IFNULL NOW, CURDATE, DAYOFMONTH, DAYOFWEEK, DAYOFYEAR, MONTH, WEEK, YEAR, CURTIME, HOUR, MINUTE, SECOND, DAYNAME, MONTHNAME
SELECT {fn MONTH(NOW())} FROM dual The SAP DB ODBC driver has extensions to the usual SQL syntax in the following areas: Database Procedures [Page 8] Cursor Functions [Page 8]

Database Procedures

Database procedures can be processed as SQL statements. See also: Reference Manual: SAP DB, Database Procedure [See SAP DB Library] section.
The ODBC syntax for procedures does not support return values of functions. Therefore, a specification in the format { ? = call.} is invalid.

Cursor Functions

The SAP DB ODBC driver supports three types of positionable cursors: static, dynamic, and keyset-driven. These differ in the extent to which changes to the database data by the current session or the sessions of other users are visible. As SAP DB can lock row-by-row, a user can change data in a table even if another user has also opened parts of this table. The prerequisite for this is that the rows to be changed are outside the part of the table that the other user has opened. Locks for individual pages or entire tables lead to significantly longer waits than row locks in operation with multiple concurrent users. Using the function SQLSetPos, an application can execute positioning INSERT, UPDATE, and DELETE statements.

ODBC-API Compatibility

In the SAP DB ODBC driver, all functions can be executed both under Microsoft Windows and under UNIX/Linux. The ODBC API is structured into the areas core, level 1, and level 2. There is an overview of the functions that are defined for the individual API compatibility levels below.
SAP AG Core API [Page 9] Level 1 API [Page 10] Level 2 API [Page 19]

Core API

Overview of the functions that are defined in the SAP DB ODBC driver for the core API Function SQLAllocConnect SQLAllocEnv SQLAllocStmt SQLBindCol Remarks If the length specification pcbValueMax is smaller than the length of a bound LONG column, the SAP DB ODBC driver returns the value SQL_NO_TOTAL for pcbValue. In all other cases, pcbValue specifies the length of the copied bytes. You can then fetch other parts of this LONG column with the SQLGetData function. SQLCancel SQLColAttributes SQLConnect SQLDescribeCol SQLDisconnect SQLError SQLExecDirect SQLExecute SQLFetch SQLFreeConnect SQLFreeEnv SQLFreeStmt SQLGetCursorName Case-sensitive, maximum length 18 characters Take this into account, for example, with the statement SELECT FOR UPDATE, as identifiers that are not enclosed in quotation marks are automatically converted into uppercase letters. The SAP DB ODBC driver constructs default values for cursor names in accordance with the following schema: SQL_CURSOR_nnnn, where nnnn corresponds to an internal counter. SQL_CUR_nnnnnnn, if n >= 10000 SQLNumResultCols -

SQLPrepare SQLRowCount

Specifies the number of affected rows for all SELECT, INSERT, DELETE statements, and so on. If no result set was created, the value -1 is displayed for the undeterminable number of affected rows.
SQLSetCursorName SQLTransact

Level 1 API

Overview of the functions that are defined in the SAP DB ODBC driver for the Level 1 API Function SQLBindParameter Remark If you want to process more than one LONG column with an INSERT, UPDATE, or DELETE statement, and bind the parameters with the attribute SQL_DATA_AT_EXECUTE, note that, for the SQLPutData function, it is only possible to assign the NULL value to one LONG column, at most. If you want to set more than one LONG column to the NULL value with only one statement, you must bind the columns in the length specification (pcbValue) using the attribute SQL_NULL_DATA. Otherwise, you receive the message szSqlState = S1000 SQLCODE =-22002. Keyword for the name of the database server: SERVERNODE Keyword for the name of the database instance: SERVERDB Remark [Page 11] Remark [Page 11] Remark [Page 14] You can determine the data types supported by the SAP DB database system using the function SQLGetTypeInfo. The following data types are supported: CHAR, VARCHAR, DECIMAL, FIXED, INTEGER, SMALLINT, FLOAT, REAL, DOUBLE PRECISION, DATE, TIME, TIMESTAMP, LONG, CHAR() BYTE, VARCHAR() BYTE, LONG BYTE, BOOLEAN If the database is configured so that Unicode characters can be processed, SAP DB also supports the following data types: CHAR() UNICODE, VARCHAR() UNICODE, LONG UNICODE SQLParamData SQLPutData For LONG columns that contain NULL values, see remark for SQLBindParameter For LONG columns that contain NULL values, see remark for SQLBi dP t 10

SQLColumns SQLDriverConnect SQLGetConnectAttr SQLGetData SQLGetFunctions SQLGetInfo SQLGetStmtAttr SQLGetTypeInfo
SAP AG SQLBindParameter SQLSetConnectAttr SQLSetParam SQLSetStmtAttr SQLSpecialColumns SQLStatistics SQLTables See SQLGetConnectAttr -
The SAP DB ODBC driver supports the following table types (szTableType): ALIAS, RESULT, SNAPSHOT, SYSTEM, SYSTEM TABLE, TABLE, UNLOADED, VIEW
Remark for SQLGetConnectAttr
List of all supported attributes and return values of the SAP DB ODBC driver Attributes
SQL_ ATTR_ACCESS_MODE SQL_ ATTR_AUTOCOMMIT SQL_ATTR_CONNECTION_DEAD SQL_ATTR_CURRENT_CATALOG SQL_ ATTR_LOGIN_TIMEOUT SQL_ATTR_ODBC_CURSORS SQL_ATTR_QUIET_MODE SQL_ ATTR_OPT_TRACE SQL_ ATTR_OPT_TRACEFILE
Return Values pvParam = SQL_MODE_READ_WRITE pvParam = SQL_AUTOCOMMIT_ON

pvParam = 15

pvParam = SQL_OPT_TRACE_OFF =0 (The filename set with SQLSetConnectAttr, default value: \SQL.LOG) pvParam = 0 pvParam = SQL_TXN_REPEATABLE_READ pvParam = (1 = INTERNAL, 2 = DB2, 3 = ANSI, 4 = ORACLE)
SQL_ ATTR_TRANSLATE_LIB SQL_ ATTR_TRANSLATE_OPTION SQL_ ATTR_TXN_ISOLATION SQL_ MODE = SQL_CONNECT_OPT_START + 2
Remark for SQLGetFunctions
If the function ID SQL_API_ODBC3_ALL_FUNCTION is specified, the macro SQL_FUNC_EXISTS returns the result TRUE for the following values: SQL_API_SQLALLOCCONNECT SQL_API_SQLALLOCENV
SAP AG SQL_API_SQLALLOCHANDLE SQL_API_SQLALLOCHANDLESTD SQL_API_SQLALLOCSTMT SQL_API_SQLBINDCOL SQL_API_SQLBINDPARAM SQL_API_SQLBINDPARAMETER SQL_API_SQLBROWSECONNECT SQL_API_SQLBULKOPERATIONS SQL_API_SQLCANCEL SQL_API_SQLCLOSECURSOR SQL_API_SQLCOLATTRIBUTES SQL_API_SQLCOLUMNPRIVILEGES SQL_API_SQLCOLUMNS SQL_API_SQLCONNECT SQL_API_SQLCOPYDESC SQL_API_SQLDATASOURCES SQL_API_SQLDESCRIBECOL SQL_API_SQLDESCRIBEPARAM SQL_API_SQLDISCONNECT SQL_API_SQLDRIVERCONNECT SQL_API_SQLDRIVERS SQL_API_SQLENDTRAN SQL_API_SQLERROR SQL_API_SQLEXECDIRECT SQL_API_SQLEXECUTE SQL_API_SQLEXTENDEDFETCH SQL_API_SQLFETCH SQL_API_SQLFETCHSCROLL SQL_API_SQLFOREIGNKEYS SQL_API_SQLFREECONNECT SQL_API_SQLFREEENV SQL_API_SQLFREEHANDLE SQL_API_SQLFREESTMT SQL_API_SQLGETCONNECTATTR SQL_API_SQLGETCONNECTOPTION SQL_API_SQLGETCURSORNAME SQL_API_SQLGETDATA SQL_API_SQLGETDESCFIELD SQL_API_SQLGETDESCREC SQL_API_SQLGETDIAGFIELD
SAP AG SQL_API_SQLGETDIAGREC SQL_API_SQLGETENVATTR SQL_API_SQLGETFUNCTIONS SQL_API_SQLGETINFO SQL_API_SQLGETSTMTATTR SQL_API_SQLGETSTMTOPTION SQL_API_SQLGETTYPEINFO SQL_API_SQLMORERESULTS SQL_API_SQLNATIVESQL SQL_API_SQLNUMPARAMS SQL_API_SQLNUMRESULTCOLS SQL_API_SQLPARAMDATA SQL_API_SQLPARAMOPTIONS SQL_API_SQLPREPARE SQL_API_SQLPRIMARYKEYS SQL_API_SQLPROCEDURECOLUMNS SQL_API_SQLPROCEDURES SQL_API_SQLPUTDATA SQL_API_SQLROWCOUNT SQL_API_SQLSETCONNECTATTR SQL_API_SQLSETCONNECTOPTION SQL_API_SQLSETCURSORNAME SQL_API_SQLSETDESCFIELD SQL_API_SQLSETDESCREC SQL_API_SQLSETENVATTR SQL_API_SQLSETPARAM SQL_API_SQLSETPOS SQL_API_SQLSETSCROLLOPTIONS SQL_API_SQLSETSTMTATTR SQL_API_SQLSETSTMTOPTION SQL_API_SQLSPECIALCOLUMNS SQL_API_SQLSTATISTICS SQL_API_SQLTABLEPRIVILEGES SQL_API_SQLTABLES SQL_API_SQLTRANSACT

SQL_CURSOR_ROLLBACK_BEHAVIOR
SQL_DATA_SOURCE_NAME SQL_DATA_SOURCE_READ_ONLY SQL_DBMS_NAME SQL_DBMS_VER SQL_DEFAULT_TXN_ISOLATION SQL_DRIVER_HDBC SQL_DRIVER_HENV SQL_DRIVER_HLIB SQL_DRIVER_HSTMT SQL_DRIVER_NAME SQL_DRIVER_ODBC_VER SQL_DRIVER_ODBC_VER SQL_DRIVER_VER
SQL_EXPRESSIONS_IN_ORDERBY SQL_FETCH_DIRECTION

SQL_FILE_USAGE

SQL_GETDATA_EXTENSIONS
rgbInfoValue = SQL_GD_ANY_COLUMN | SQL_GD_ANY_ORDER | SQL_GD_ANY_BOUND | SQL_GD_ANY_BLOCK rgbInfoValue = SQL_GB_GROUP_BY_CONTAINS_SELECT rgbInfoValue = 1 (SQL_IC_UPPER) rgbInfoValue = "\"" rgbInfoValue = "N" rgbInfoValue = (List of key words, dependent on SQLMode) rgbInfoValue = "Y" rgbInfoValue = 1 SQL_LCK_NO_CHANGE rgbInfoValue = 0 rgbInfoValue = 0 rgbInfoValue = 0 rgbInfoValue = 32 rgbInfoValue = 128 rgbInfoValue = 16 rgbInfoValue = 128 rgbInfoValue = 1023 rgbInfoValue = 1023 rgbInfoValue = 32767 rgbInfoValue = 32 rgbInfoValue = 0 rgbInfoValue = 1024 rgbInfoValue = 32 rgbInfoValue = 32 rgbInfoValue = 0 rgbInfoValue = 0 rgbInfoValue = "N" rgbInfoValue = 32 rgbInfoValue = 0 rgbInfoValue = 32 rgbInfoValue = 64 rgbInfoValue = 32 rgbInfoValue = "Y" rgbInfoValue = "Y"
SQL_GROUP_BY SQL_IDENTIFIER_CASE SQL_IDENTIFIER_QUOTE_CHAR SQL_INTEGRITY SQL_KEYWORDS SQL_LIKE_ESCAPE_CLAUSE SQL_LOCK_TYPES SQL_MAX_BINARY_LITERAL_LEN SQL_MAX_CATALOG_NAME_LEN SQL_MAX_CHAR_LITERAL_LEN SQL_MAX_COLUMN_NAME_LEN SQL_MAX_COLUMNS_IN_GROUP_BY SQL_MAX_COLUMNS_IN_INDEX SQL_MAX_COLUMNS_IN_ORDER_BY SQL_MAX_COLUMNS_IN_SELECT SQL_MAX_COLUMNS_IN_TABLE SQL_MAX_CONCURRENT_ACTIVITIES SQL_MAX_CURSOR_NAME_LEN SQL_MAX_DRIVER_CONNECTIONS SQL_MAX_INDEX_SIZE SQL_MAX_OWNER_NAME_LEN SQL_MAX_PROCEDURE_NAME_LEN SQL_MAX_QUALIFIER_NAME_LEN SQL_MAX_ROW_SIZE SQL_MAX_ROW_SIZE_INCLUDES_LONG SQL_MAX_SCHEMA_NAME_LEN SQL_MAX_STATEMENT_LEN SQL_MAX_TABLE_NAME_LEN SQL_MAX_TABLES_IN_SELECT SQL_MAX_USER_NAME_LEN SQL_MULT_RESULT_SETS SQL_MULTIPLE_ACTIVE_TXN
SQL_NEED_LONG_DATA_LEN SQL_NON_NULLABLE_COLUMN SQL_NULL_COLLATION SQL_NUMERIC_FUNCTIONS
rgbInfoValue = "N" rgbInfoValue = 1 (SQL_NNC_NON_NULL) rgbInfoValue = 1 (SQL_NC_LOW) rgbInfoValue = SQL_FN_NUM_ABS | SQL_FN_NUM_ACOS | SQL_FN_NUM_ASIN | SQL_FN_NUM_ATAN | SQL_FN_NUM_ATAN2 | SQL_FN_NUM_CEILING | SQL_FN_NUM_COS | SQL_FN_NUM_COT | SQL_FN_NUM_EXP | SQL_FN_NUM_FLOOR | SQL_FN_NUM_LOG | SQL_FN_NUM_MOD | SQL_FN_NUM_SIGN | SQL_FN_NUM_SIN | SQL_FN_NUM_SQRT | SQL_FN_NUM_TAN | SQL_FN_NUM_PI | SQL_FN_NUM_DEGREES | SQL_FN_NUM_RADIANS | SQL_FN_NUM_ROUND rgbInfoValue = 2 (SQL_OAC_LEVEL2) rgbInfoValue = 1 (SQL_OSCC_COMPLIANT) rgbInfoValue = 2 (SQL_OSC_EXTENDED) rgbInfoValue = "N" rgbInfoValue = "03.520000" rgbInfoValue = "N" rgbInfoValue = "Y" rgbInfoValue = "Owner" rgbInfoValue = SQL_OU_DML_STATEMENTS | SQL_OU_PROCEDURE_INVOCATION | SQL_OU_TABLE_DEFINITION | SQL_OU_INDEX_DEFINITION | SQL_OU_PRIVILEGE_DEFINITION rgbInfoValue = SQL_POS_UPDATE | SQL_POS_DELETE | SQL_POS_ADD (only allowed with dynamic cursors) | SQL_POS_POSITION | SQL_POS_REFRESH rgbInfoValue = SQL_PS_POSITIONED_DELETE | SQL_PS_POSITIONED_UPDATE | SQL_PS_SELECT_FOR_UPDATE rgbInfoValue = "stored procedure"

SQL_ODBC_API_CONFORMANCE SQL_ODBC_SAG_CLI_CONFORMANCE SQL_ODBC_SQL_CONFORMANCE SQL_ODBC_SQL_OPT_IEF SQL_ODBC_VER SQL_ORDER_BY_COLUMNS_IN_SELECT SQL_OUTER_JOINS SQL_OWNER_TERM SQL_OWNER_USAGE

SQL_POS_OPERATIONS

SQL_POSITIONED_STATEMENTS

SQL_PROCEDURE_TERM

SQL_PROCEDURES SQL_QUALIFIER_LOCATION SQL_QUALIFIER_NAME_SEPARATOR SQL_QUALIFIER_TERM SQL_QUALIFIER_USAGE SQL_QUOTED_IDENTIFIER_CASE SQL_ROW_UPDATES SQL_SCHEMA_TERM SQL_SCHEMA_USAGE
rgbInfoValue = "Y" rgbInfoValue = 1 (SQL_CL_START) rgbInfoValue = "." rgbInfoValue = "Qualifier" rgbInfoValue = 0x00000000 rgbInfoValue = 3 (SQL_IC_SENSITIVE) rgbInfoValue = "Y" rgbInfoValue = "Owner" rgbInfoValue = SQL_OU_DML_STATEMENTS | SQL_OU_PROCEDURE_INVOCATION | SQL_OU_TABLE_DEFINITION | SQL_OU_INDEX_DEFINITION | SQL_OU_PRIVILEGE_DEFINITION rgbInfoValue = SQL_SCCO_READ_ONLY | SQL_SCCO_LOCK | SQL_SCCO_OPT_ROWVER | SQL_SCCO_OPT_VALUES rgbInfoValue = SQL_SO_FORWARD_ONLY | SQL_SO_KEYSET_DRIVEN | SQL_SO_DYNAMIC | SQL_SO_STATIC rgbInfoValue = "\" rgbInfoValue = (Name of the database server) rgbInfoValue = "#@$" rgbInfoValue = 0x00000000 rgbInfoValue = SQL_FN_STR_LEFT | SQL_FN_STR_LTRIM | SQL_FN_STR_LENGTH | SQL_FN_STR_LCASE | SQL_FN_STR_REPLACE | SQL_FN_STR_RIGHT | SQL_FN_STR_RTRIM | SQL_FN_STR_SUBSTRING | SQL_FN_STR_UCASE | SQL_FN_STR_SOUNDEX rgbInfoValue = SQL_SQ_COMPARISON | SQL_SQ_EXISTS | SQL_SQ_IN | SQL_SQ_CORRELATED_SUBQUERIES rgbInfoValue = SQL_FN_SYS_USERNAME | SQL_FN_SYS_DBNAME | SQL_FN_SYS_IFNULL rgbInfoValue = "Table"

SQL_SCROLL_CONCURRENCY

SQL_SCROLL_OPTIONS
SQL_SEARCH_PATTERN_ESCAPE SQL_SERVER_NAME SQL_SPECIAL_CHARACTERS SQL_STATIC_SENSITIVITY SQL_STRING_FUNCTIONS

SQL_SUBQUERIES

SQL_SYSTEM_FUNCTIONS

SQL_TABLE_TERM

SQL_TIMEDATE_ADD_INTERVALS SQL_TIMEDATE_DIFF_INTERVALS SQL_TIMEDATE_FUNCTIONS
rgbInfoValue = 0x00000000 rgbInfoValue = 0x00000000 rgbInfoValue = SQL_FN_TD_NOW | SQL_FN_TD_CURDATE | SQL_FN_TD_DAYOFMONTH | SQL_FN_TD_DAYOFWEEK | SQL_FN_TD_DAYOFYEAR | SQL_FN_TD_MONTH | SQL_FN_TD_WEEK | SQL_FN_TD_YEAR | SQL_FN_TD_CURTIME | SQL_FN_TD_HOUR | SQL_FN_TD_MINUTE | SQL_FN_TD_SECOND | SQL_FN_TD_DAYNAME | SQL_FN_TD_MONTHNAME rgbInfoValue = 2 (SQL_TC_ALL) rgbInfoValue = SQL_TXN_READ_UNCOMMITTED | SQL_TXN_READ_COMMITTED | SQL_TXN_REPEATABLE_READ | SQL_TXN_SERIALIZABLE rgbInfoValue = SQL_U_UNION | SQL_U_UNION_ALL rgbInfoValue = (Name of the active user)
SQL_TXN_CAPABLE SQL_TXN_ISOLATION_OPTION

SQL_UNION

SQL_USER_NAME

Level 2 API

Overview of the functions that are defined in the SAP DB ODBC driver for the Level 2 API Function SQLBrowseConnect SQLColumnPrivileges SQLDataSources (*) SQLDescribeParam SQLExtendedFetch You can only insert rows using the function with the dynamic cursor model (SQL_CURSOR_DYNAMIC). This is not possible with any other cursor models. UPDATE and DELETE statements are possible both with the static (SQL_CURSOR_STATIC) and with the keyset-driven cursor (SQL_CURSOR_KEYSETDRIVEN) models. SQLFetchScroll SQLForeignKeys SQLMoreResults The function calls SQLFreeStmt with the attribute SQL_CLOSE to close h i l d h 19 Remark

November 2002 the previous result set and then returns SQL_NO_DATA_FOUND.
SQLNativeSql SQLNumParams SQLParamOptions SQLPrimaryKeys SQLProcedureColumns SQLProcedures SQLSetPos All attributes are permissible. The attribute SQL_ADD is only possible in the dynamic cursor model (SQL_CURSOR_DYNAMIC). Only the attribute SQL_LOCK_NO_CHANGE is permissible for the fLock argument.
SQLSetScrollOptions SQLTablePrivileges

Unicode Support

The SAP DB ODBC driver supports Unicode. This means that the functions listed below are also available, irrespective of whether the data source supports Unicode or not.
Under Microsoft Windows, the Driver Manager basically uses the Unicode variants of the ODBC API. If, for example, the SQLConnect function is called within the application, SQLConnectW is called in the ODBC driver. The conversions between ASCII and Unicode are performed by the Driver Manager. Overview of the functions that are defined in the SAP DB ODBC driver for access to Unicode data SQLBrowseConnectW SQLColAttributesW SQLColAttributeW SQLColumnPrivilegesW SQLColumnsW SQLConnectW SQLDataSourcesW SQLDescribeColW SQLDriverConnectW SQLDriversW SQLErrorW SQLExecDirectW SQLForeignKeysW SQLGetConnectAttrW
SAP AG SQLGetConnectOptionW SQLGetCursorNameW SQLGetDescFieldW SQLGetDescRecW SQLGetDiagFieldW SQLGetDiagRecW SQLGetInfoW SQLGetStmtAttrW SQLGetTypeInfoW SQLNativeSqlW SQLPrepareW SQLPrimaryKeysW SQLProcedureColumnsW SQLProceduresW SQLSetConnectAttrW SQLSetConnectOptionW SQLSetCursorNameW SQLSetDescFieldW SQLSetStmtAttrW SQLSpecialColumnsW SQLStatisticsW SQLTablePrivilegesW SQLTablesW
SAP DB ODBC Driver Under Microsoft Windows
Installation Under Microsoft Windows [Page 21] Creating Data Sources Under Microsoft Windows [Page 23]
Installation Under Microsoft Windows
You have various options for installing the SAP DB ODBC driver under Microsoft Windows: As part of the SAP DB server package As a separate software package, such as for purely client installations
These options differ only in the default value of the system for storing the installed software. If you install the SAP DB ODBC driver as part of the server package, the system default value for the installation path up to database version 7.3 is the <dependent_data_path>, as of database version 7.4, the <independent_data_path>.
If you install the SAP DB ODBC driver as a separate software package, the default value for the system is the installation path C:\Program Files\SAP DB\ODBC7x, where x stands for the particular version of the SAP DB ODBC driver.

As of version 7.4, the ODBC installation package is included not only in the server package, but also in the Web Tools package and in the DB Analyzer package. The combination of the software packages corresponds to different installation profiles. You can install the entire software package; that is, including ODBC software, or select only the ODBC installation package from the software package. See also: Installation Guidelines: SAP DB 7.4, Installation Profile [See SAP DB Library] section

Procedure

Check whether a SAP DB Server is already installed on your server. If this is the case, the SAP DB ODBC driver is also already installed, and no further steps are necessary. Otherwise, proceed as follows: Open the InstallShield Wizard for the SAP DB ODBC driver by double clicking the file odbc7x-setup.exe. The default value for the installation path is C:\Program Files\SAPDB\ODBC7x. You can change this installation path. Follow the instructions in the Wizard.

Result

Information about all installed ODBC drivers is stored by the system in the file HKEY_LOCAL_MACHINE/SOFTWARE/ODBC/ODBCINST.INI. A driver-specific key is also created for each ODBC driver, and is also stored in this file. The following entry is stored in the registry for the SAP DB ODBC driver during installation: HKEY_LOCAL_MACHINE SOFTWARE\ODBC\ODBCINST.INI SAP DB 7.4 The key SAP DB 7.4 is created. The names of the ODBC driver DLLS and the name of the setup DLL are stored under the driver-specific key. The ODBC Administrator tool uses this information to load the corresponding DLL when creating new data sources. Under the key SAP DB 7.4, there is the following entry: HKEY_CURRENT_USER SOFTWARE\ODBC\ODBCINST.INI\SAP DB 7.4 Driver=C:\SAP DB\pgm\sqlod32.dll Setup=C:\SAP DB\pgm\sqlsp32.dll
Creating Data Sources Under Microsoft Windows
You can create data sources using the ODBC Administrator tool. The specifications for the data sources are stored by the system in the file HKEY_CURRENT_USER/Software/ODBC/ODBC.INI.
1. Choose Start Settings Control Panel Administrative Tools Data Sources (ODBC). This opens the ODBC Data Source Administrator. 2. Choose Add. 3. From the displayed list of the installed ODBC drivers, choose the entry SAP DB and confirm your choice by choosing Finish. 4. Make the following entries: Data Source Name Name of the data source. The data source is identified using this name. Use this name to simplify logging on to the database server. The name of the data source may not contain any special characters. Description of the data source Name of the database instance Name of the database server.If the database instance and the application are on the same server, you do not need to fill out this field.
Description Database Name Database Server
5. If you want to specify options for the new data source, choose Settings. Proceed with the entry of Options for the Data Source [Page 23]. If you do not want to specify any options, choose OK. Your entries become effective when the next ODBC connection is created.

Options for Data Sources (Microsoft Windows)
You can specify various options to influence the functioning of the SAP DB ODBC driver. These options become active the next time that you log on to the database server. The following options are possible: Option SQL Mode [Page 24] Isolation Level [Page 24] Trace On [Page 25] Remarks Select the database-specific SQL mode Overrides the default value of the SAP DB ODBC driver for the lock operation type (the default value is Committed). Activates or deactivates the driver log. If you have set this option, the SAP DB ODBC driver creates a log of the database session. All SQL statements that the application transfers to the database system are recorded in the log. A large number of file operations are performed if you activate logging. This affects the execution speed of the application. You should therefore deactivate logging again after your analysis. This driver logging is not identical to the Driver Manager log,
November 2002 which you can activate and deactivate in the ODBC Data Source Administrator on the Tracing tab page.
SQL Mode (Microsoft Windows)
If you specify the option SQL Mode, you can use the SAP DB ODBC driver in a different SQL mode. This means that the driver can process not only the ODBC and SAP DB-specific SQL syntax, but also the ORACLE or DB2 syntax, for example. Specifying this option can simplify the customization of SQL statements during the migration from ODBC applications from other database systems.
For a description of the SAP DB-specific SQL mode INTERNAL, see the Reference Manual: SAP DB 7.4, SQL Mode [See SAP DB Library] section.
1. Start the ODBC Data Source Administrator by choosing Start Settings Control Panel Administrative Tools Data Sources. 2. Choose Add. 3. Choose the SAP DB ODBC driver and then Finish. 4. Specify the name of the data source, the name of the database instance, and the name of the database server. Choose Options. 5. In the SQL Mode field, choose the desired SQL mode. 6. Confirm the windows until the ODBC Data Source Administrator closes.
The next time that you log on to the database server using this data source, the SAP DB ODBC driver functions in the selected SQL mode.

Use with a Driver Manager
Using a Driver Manager, such as iODBC or unixODBC simplifies the exchange of ODBC drivers and allows the concurrent use of different ODBC drivers. The relevant documentation describes how you integrate an ODBC driver into the Driver Manager.
Use without a Driver Manager
If you are not using a Driver Manager, you must use an editor to enter the data for the SAP DB ODBC driver manually, either in the file ~/.odbc.ini or the file /var/spool/sql/ini/odbc.ini.
The system first uses the valid.odbc.ini file for the respective user from his or her home directory during the assignment of data sources. If no suitable data source is found there, the system evaluates the file /var/spool/sql/ini/odbc.ini.
Using the ODBC Driver without a Driver Manager Compiler command: Compile the ODBC application myapp.c with appropriate ODBC header files cc c myapp.c I<ODBC_include> Link command for static library: Static linking of the application myapp cc o myapp myapp.o <ODBC_lib>/libsqlod.a
SAP AG Link command for dynamic library: Dynamic linking of the application myapp cc o myapp myapp.o L<ODBC_lib> -lsqlod
Creating and Changing Data Sources Under UNIX/Linux
Under the UNIX and Linux operating systems, data sources are stored system-specifically in the directory /var/spool/sql/config/ in the file odbc.ini or user-specifically in the file ~/.odbc.ini. To create data sources, edit the desired file appropriately.
1. Open an editor. 2. Open the desired file. Specify the name of the data source, the database server, and the database instance in accordance with the following structure: You can also specify Options for Data Sources [Page 28], if you want to change the system default values. [<data_source_name>] ServerDB=<database_name> ServerNode=<name_of_database_server> SQLMode=<INTERNAL|DB2|ANSI|ORACLE> IsolationLevel=<Uncommitted|Committed|Repeatable|Serializable> TraceFileName=<trace_file_path_and_name> If you want to specify multiple data sources, repeat the group of specifications above in accordance with the number of data sources. 3. Save your entries. Your entries become effective when the next ODBC connection is created.

Options for Data Sources (UNIX/Linux)
You can specify various options to influence the functioning of the SAP DB ODBC driver. These options become active the next time that you log on to the database server. The following options are possible: Option SQLMode [Page 29] IsolationLevel [Page 29] TraceFileName [Page 30] Remark Select the database-specific SQL mode (default value is INTERNAL) Overrides the default value of the SAP DB ODBC driver for the isolation level (the default value is Committed). Activates or deactivates the driver log for logging the SQL statements (Default value: No log is written). If you have set this option, the SAP DB ODBC driver creates a log of the database session. All SQL statements that the application sends to
SAP AG the database system are recorded in the log.
A large number of file operations are performed if you activate logging. This affects the execution speed of the application. You should therefore deactivate logging again after your analysis.

SQL Mode (UNIX/Linux)

By changing the option SQLMode, you can use the SAP DB ODBC driver in a different SQL mode. This means that the driver can process not only the ODBC and SAP DB-specific SQL syntax, but also the ORACLE or DB2 syntax, for example. The system default value is INTERNAL (see also: Reference Manual: SAP DB 7.4, SQL Mode [See SAP DB Library] section). If you migrate ODBC applications from other database systems, specifying this option can simplify the customization of the SQL statements.

Syntax

SQLMode = INTERNAL | DB2 | ANSI | ORACLE
To change the SQLMode option, follow the procedure described under Creating and Changing Data Sources Under UNIX/Linux [Page 28]. The value defined in this way then applies for all connections of the data source.
Isolation Level (UNIX/Linux)
SAP DB allows concurrent transactions on database objects. To do this, it uses a lock concept that creates locks on rows and tables to contain individual transactions. The lock operation type plays an important role in this. This is determined by defining an isolation level. The system default value for the lock operation type is Committed. The set lock operation type can be overridden by the application using the function SQLSetConnectAttr and queried with SQLGetConnectAttr.
IsolationLevel = Uncommitted | Committed | Repeatable | Serializable Overview of the possible lock operation types Dirty Read Uncommitted Committed Repeatable Serializable x Non-repeatable Read x x Phantom Read x x x

To change the IsolationLevel option, follow the procedure described under Creating and Changing Data Sources Under UNIX/Linux [Page 28]. The value defined in this way then applies for all connections of the data source.
Logging SQL Statements (UNIX/Linux)
The SQL statements transferred by the application to the database instance can be logged in a file. The following data is recorded: SQL statement Execution time Start and end of a session CONNECT parameters Input and output parameters
Only one application can write to each log file. If this option is not set, no log is written (system default value).
TraceFileName = <file_name> <file_name> ::= [<path_name>/]file_identifier
To change the TraceFileName option, follow the procedure described under Creating and Changing Data Sources Under UNIX/Linux [Page 28].
Installed Files (UNIX/Linux)
Overview of the Files created during installation and their functions The files are specified relative to the respective installation directory. (See also: Installation Under UNIX/Linux [Page 26]) Filename libsqlod.a, libsqlod.so incl/sql.h incl/sqlext.h incl/sqltypes.h incl/WINDOWS.H demo/eng/ODBC/sqlexamp.c demo/eng/ODBC/sqladhoc.c demo/eng/ODBC/Makefile Description SAP DB ODBC driver library ODBC driver header file (Core API) ODBC driver header file (Level 1 API and Level 2 API) ODBC driver header file (Data types) Header file for the UNIX/Linux platforms C example program for an ODBC application C example program for an ODBC application Make file for generating a demo program