Browse Prior Art Database

Implicit version control for ODBC/CLI application

IP.com Disclosure Number: IPCOM000013709D
Original Publication Date: 2001-Sep-10
Included in the Prior Art Database: 2003-Jun-18
Document File: 4 page(s) / 98K

Publishing Venue

IBM

Abstract

Implicit version control for ODBC/CLI application I. Introduction. Many software products provide APIs (Application Programming interface) for ISVs (Independent Software Vendor) to develop function specific Client applications. These days, as the time between each release cycle has been dramatically reduced, the compatibility issues between Client Applications and Server Products become a serious problem. For example, a Client Application built with IBM DB2 Everyplace V7 may crash the system if it runs on top of a DB2 Everyplace V1 backend. The same theory also applies to Client Applications built with previous release of a Server product but employing a later released backend Server. This research disclosure addresses these problems. It provides a method to pass Client side version number implicitly to the backend Server for checking at run time. A checking algorithm at the server side is also included. This idea can be applied to all the software products supporting APIs in general, and not limited to ODBC (Open Database Connectivity)/CLI (Call Level Interface) applications. II. Overview The most common way to solve this problem is to put version compatibility requirements in the release note. But this is error prone and put burden on developers and users.This technique utilizes the C/C++ header file to contain a version number, which will be compiled into the application executables. This version number is then passed to the backend server at run time through function mappings. Here we map the initialization function(s) of the API that Client applications have to invoke to a corresponding new function(s) that contains one extra “Version Number “parameter. After checking the Client version number, backend Server can return error messages and stop the process, return specific version compatibility messages, or just continue if the Client Application is compatible. Since developers can manually modify the header file, we recommend encrypting this version number in the header file and decrypting it at the server side.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 49% of the total text.

Page 1 of 4

Implicit version control for ODBC/CLI application

Implicit version control for ODBC/CLI application
I. Introduction. Many software products provide APIs (Application Programming interface) for ISVs (Independent Software Vendor) to develop function specific Client applications. These days, as the time between each release cycle has been dramatically reduced, the compatibility issues between Client Applications and Server Products become a serious problem. For example, a Client Application built with IBM DB2 Everyplace V7 may crash the system if it runs on top of a DB2 Everyplace V1 backend. The same theory also applies to Client Applications built with previous release of a Server product but employing a later released backend Server. This research disclosure addresses these problems. It provides a method to pass Client side version number implicitly to the backend Server for checking at run time. A checking algorithm at the server side is also included. This idea can be applied to all the software products supporting APIs in general, and not limited to ODBC (Open Database Connectivity)/CLI (Call Level Interface) applications.

II. Overview

The most common way to solve this problem is to put version compatibility requirements in the release note. But this is error prone and put burden on developers and users.This technique utilizes the C/C++ header file to contain a version number, which will be compiled into the application executables. This version number is then passed to the backend server at run time through function mappings. Here we map the initialization function(s) of the API that Client applications have to invoke to a corresponding new function(s) that contains one extra "Version Number "parameter. After checking the Client version number, backend Server can return error messages and stop the process, return specific version compatibility messages, or just continue if the Client Application is compatible. Since developers can manually modify the header file, we recommend encrypting this version number in the header file and decrypting it at the server side.

The standard ODBC has a function "SQLSetEvnAttr()." With the SQL_ATTR_ODBC_VERSION attribute, developers can indicate the ODBC version he/she intends to use. But this requires the version number be explicitly specified. Calling this function is also not enforced by IBM DB2 Everyplace or UDB.

III. Methodology.

This version checking technique encompasses two parts: (1) a method to implicitly pass Client version number to Server, and (2) an algorithm to check version at the server side as described

1

Page 2 of 4

below. A method to implicitly pass Client version number to Server Step 1: Declare version number with the function declarations in the C/C++ header files that application developers have to use to compile/build executables.

Step 2: Identify API function (or functions) that have to be invoked at start up time. Using C/C++ Macro to map this function to a different n...