Browse Prior Art Database

Implicit version control for ODBC/CLI application Disclosure Number: IPCOM000013709D
Original Publication Date: 2001-Sep-10
Included in the Prior Art Database: 2003-Jun-18

Publishing Venue



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.