Browse Prior Art Database

Technique for Implementing Context Sensitive Text Replacement

IP.com Disclosure Number: IPCOM000100280D
Original Publication Date: 1990-Mar-01
Included in the Prior Art Database: 2005-Mar-15
Document File: 3 page(s) / 123K

Publishing Venue

IBM

Related People

Chen, YS: AUTHOR [+3]

Abstract

This invention detects relational database object name occurrences within a syntactically correct SQL source statement and selectively replaces a (proper) subset of those occurrences with new object names, based upon both the context of the object within the source SQL statement and the type of the object as defined within the local database catalog.

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

Technique for Implementing Context Sensitive Text Replacement

       This invention detects relational database object name
occurrences within a syntactically correct SQL source statement and
selectively replaces a (proper) subset of those occurrences with new
object names, based upon both the context of the object within the
source SQL statement and the type of the object as defined within the
local database catalog.

      In SQL objects of distinct types (e.g., tables, views,
synonyms, columns) share a single name space.  Two distinct objects
may be known by the same name, and the distinction between the
objects can only be deduced from the context of the name within the
SQL statement.

      For example, a Relational table and one of its constituent
columns, as well as a host variable within the application code, may
all be named ABC.  If this is the case, the distinction between the
column, table, host variable, all named ABC, within the following SQL
statement must be inherent within the syntactical representation or
PARSE of the SQL string:
            SELECT ABC FROM ABC INTO:ABC;

      Within a distributed database environment which supports object
location transparency, the SQL Application Programming Interface (SQL
API) must be strengthened to support access to local objects, which
map to access to remote  objects.  In response to this requirement,
an ALIAS object is created locally and provides the local linkage to
a remote table or view.  The ALIAS object shares the name space of
other local database objects and is effectively a pointer to a
different object (either a table or a view) which resides at a remote
database instance, where it is possibly known by a different name.
Prior to processing any SQL statement which accesses objects of type
ALIAS, the local DBMS must ensure that the ALIAS represents a
table/view at some remote DBMS instance, and substitute the name of
that table or view (as it is known at the remote database instance)
within the SQL source statement.  Since ALIAS objects share the name
space with other local database objects, e.g., tables/views, etc.,
the text replacement must be performed with sensitivity to both
object type and object context.

      In the example shown above, if ABC is identified as an ALIAS
existing at a remote database instance where it is known by the name
DEF, then simple text replacement which ignores object type and
context would yield the following syntactically correct SQL
statement:
 SELECT DEF FROM DEF INTO :DEF;

      However, this replacement does not distinguish the context of
the ALIAS object from either the column object or the host variable.
The correct text replacement would yield:
            SELECT ABC FROM DEF INTO:ABC;

      The parse of an SQL statement produces a "parse tree", a
syntactical representation of the SQL text.  The context and names of
relational objects are known when the SQL statement is par...