Very Computer

Embedded SQL is fine for cases were aprori (sp?) knowledge of the request(s)
is available.  A browser or user front-end for ad hoc queries is NOT such an
animal and therefore the embedded SQL approach is almost useless.
For our AI interface, not only do we access any table (within authority
constraints) but also any projection of any join subset thereof.  As
an attribute name may not be used as an SQL variable, the embedded approach
will never be the functional equivalent of SOME OCI operations.

For example, let EMP be a table containing four attributes, EMPNO,NAME,DEPT,MGR.
To use embedded SQL to access one attribute at a time, four separate queries
are required ( select ATTNAME from EMP; ).  To cover all permutations requires
 !4 or 24 unique queries.  The OCI functions {osql3,odefin,obndrv}() allow
one to specify exactly the attributes required by the user and avoid the
simplistic SELECT * from Table approach, thus saving large IPC transfers and
poor DBMS performance.  It also allows correct table joins ( you can't get
a decent join using ( select * from T1,T2 ).

Some other vendors like to say "...then why not try <My product name> ...".
They too fall into this pit with their software.  Worse yet, at least
one un-named vendor has embedded SQL but without the dynamic SQL feature.

Embedded SQL is just fine where the user front-end collects sufficient
information to invoke a given transaction.  The mappings and implementation
are straight forward.  Ad hoc browsers require more flexibility than currently
present in embedded SQL implementations.

===
Opinions are the possession of the speaker and to assert otherwise
is plagiarism.

Jeff Beard, Quintus Computer Systems, Inc.

e-mail ...!amdahl!sun!quintus!jbeard
phone  (415) 965-7700

Correct.  The problem statement, if you will.

Quote:>The OCI functions {osql3,odefin,obndrv}() allow
>one to specify exactly the attributes required by the user

As do parameterized queries, such as are supported by INGRES Corp.
Another point in the solution space.  The power is identical, the
functionality is identical, and the portability is identical.

Quote:>Embedded SQL is just fine where the user front-end collects sufficient
>information to invoke a given transaction.  The mappings and implementation
>are straight forward.  Ad hoc browsers require more flexibility than currently
>present in embedded SQL implementations.

Parameterized queries allow mechanical construction and execution of
parameterized screen operations that correspond to the database
operations.  For instance, one can build a generalized browser that
acts on any database, displaying the fields presented any screen form,
by consulting the system catalogs at runtime.  I have done this and it
works.

Therefore, this would appear to offer a counterexample.  In point of
fact it doesn't; I used a more orthogonal query language than SQL.  But
the principle still applies: embedded SQL can express what is needed by
browsers.  Certain extensions are necessary, but their use is neither
better nor worse than function call interfaces.  Neither provides a
very rigorous model for modifying and transforming queries, but that's
another story.

-- Jon
--

Isn't it interesting that the first thing you do with your
color bitmapped window system on a network is emulate an ASR33?