Browse Prior Art Database

SQL Development Integrity Diagnostic Disclosure Number: IPCOM000107387D
Original Publication Date: 1992-Feb-01
Included in the Prior Art Database: 2005-Mar-21
Document File: 3 page(s) / 112K

Publishing Venue


Related People

Johnson, WJ: AUTHOR [+3]


A program is described which diagnoses the Database Manager (DB MGR) DB/2* family of bind errors.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 44% of the total text.

SQL Development Integrity Diagnostic

       A program is described which diagnoses the Database
Manager (DB MGR) DB/2* family of bind errors.

      Standard Query Language (SQL) development introduces a new set
of errors which developers and users must be aware to avoid. SQL bind
errors are very common in applications which use SQL. These are
troublesome to find when many SQL-related object files were used to
construct an executable (.EXE) or dynamic link library (.DLL).
Development of SQL code often produces problems resulting in bind
errors returned from the DB MGR when attempting to run SQL code
against a database. This tool will help find a bind error and will
save the programmer much time spent in comparing date-time stamps of
many object code modules, DLLs and bind files. Furthermore, this tool
is useful in determining SQL code integrity (i.e., make sure all
latest development changes are incorporated) and correctness before
code is introduced into the hands of a customer. This article also
describes a means for validating a build process is designed properly
when building a system utilizing SQL.

      This article describes a program which is started from an OS/2*
or DOS command line. The date-time compare rule which must be true
whenever SQL code is free of bind errors and has integrity (for each
SQL.SQC file i) is:
(i.SQC <) i.BND < (i.C <) i.OBJ < ????????.EXE with static linked
(i.SQC <) i.BND < (i.C <) i.OBJ < ????????.DLL with linked i.OBJ

      Note while date-time stamps on the .SQC and .C files do not
relate to the bind errors, further code integrity can be checked by
checking these files as well (integrity checks are bracketed). Input
of bind files can be done by simply scanning the system or providing
directories and starting with what is found. Further input to the
tool can be provided to facilitate searching. This article describes
a tool which saves the user or programmer much time in determining
why the DB MGR is returning bind error(s) when trying to run an
application against a DB/2 database. Also, it eliminates time in
guess work in determining if the system properly reflects all current
SQL code changes. The following items may be implemented in a variety
of ways and still be covered within the scope of the present article:
      1.   Search criteria provided (e.g., may know just executables
(.EXEs) using DB)
      2.   Integrity check ON/OFF
      3.   REPORT message format(s)
      4.   Provide fully qualified paths for all file names on report
      5.   Programmer taste in implementation
      6.   File size can also be used in determining other types of
integrity which are not demonstrated herein
      One embodiment pseudo code for the present article
implementation follows:
      DEFINITION: TUPLE = a 3-part record consisting of a file name,
file size and file time-stamp.