marti@ethz.UUCP (Robert Marti) (08/04/87)
The prevalent approach to offer set-oriented access to a relational
database from an application written in a langauge such as C seems
to be pre-compilation. For example, embedded SQL uses database
statements bracketed by EXEC SQL and END-EXEC keywords while embedded
QUEL uses the ## marker on the beginning of each line. The pre-
processor strips these statements and replaces them by procedure
calls to the DBMS.
There are two drawbacks to such a solution: The first and minor one
is that such constructs look unpleasant in the source. The second
and major drawback is that a pre-processor has to written for each
new host language for which database access has to be supported.
This may be OK for vendors who can easily tailor their existing
pre-processor to a new language, but for customers without access
to source this is a major pain (you know where :-)
Since we would like to use Modula-2 to access relational databases
-- Modula-2 is the language our programmers (students) know best --
we'd much rather have an interface in the form of a library of
procedures. An example of such an interface is provided by Sun's
enhanced version of UNIFY which supports query_open, query_next
and query_close statements as shown below:
char[30] emp_name;
int emp_sal;
cursor = query_open("select name, salary from emp");
while (query_next(cursor, "%s %d", emp_name, &emp_sal) == DB_SUCCESS) {
/* process the retrieved stuff */
}
query_close(cursor);
(Note that the "%s %d" string in query_next is a format string as used
in the well-known scanf, printf etc. functions.)
Unfortunately, UNIFY is weak in other areas, namely in its support for
transactions and views. Therefore my questions: Are there any other
UNIX DBMS products out there which support relational queries via a
call interface as opposed to a pre-processor? Do INGRES or Oracle
explain in their manuals how to interface to their database system
without using the pre-processor?
Thanks in advance for any explanations on the subject.
Bob
--
Robert Marti Phone: +41 1 256 52 36
Institut fur Informatik
ETH Zentrum/SOT CSNET/ARPA: marti%ifi.ethz.ch@relay.cs.net
CH-8092 Zurich, Switzerland UUCP: ...seismo!mcvax!ethz!martilarry@xanadu.uucp (Larry Rowe) (08/06/87)
In article <168@bernina.UUCP> marti@ethz.UUCP (Robert Marti) writes: >The prevalent approach to offer set-oriented access to a relational >database from an application written in a langauge such as C seems >to be pre-compilation. For example, embedded SQL uses database >statements bracketed by EXEC SQL and END-EXEC keywords while embedded >QUEL uses the ## marker on the beginning of each line. The pre- >processor strips these statements and replaces them by procedure >calls to the DBMS. > ..... i think you could define such an interface for any of the major DBMS's that are offered commercially. the preprocessor that you mention just translates from a ``user friendly'' notation to an ``ugly'' subroutine call interface. you could define your own subroutine call interface that in turn did calls on the vendor supplied routines. a couple of things to look out for though: 1. most vendors don't guarantee compatibility at the subroutine call level between releases. (it doesn't change often, but changes are needed periodically to add functionality and fix bugs.) 2. this solution assumes that the subroutine call interface can be linked into your program. on the vax and 68K/unix this is possible because all languages use a standard subroutine call interface. i don't recall what machine you are using or what modula compiler you are using, but this might present a problem. finally, as to whether any commercial database vendors publish the protocol between the application program and the dbms program (typically an IPC protocol), i don't know of anyone who is doing this yet, but i expect there will bbe many people arguing over this issue as distributed heterogenous dbms's become more widely used. there is an ISO standards committee looking into this, but i don't get the sense that anyone is paying any attention to them. larry
pavlov@hscfvax.UUCP (840033@G.Pavlov) (08/07/87)
In article <168@bernina.UUCP>, marti@ethz.UUCP (Robert Marti) writes: > ........................ Therefore my questions: Are there any other > UNIX DBMS products out there which support relational queries via a > call interface as opposed to a pre-processor? Do INGRES or Oracle > explain in their manuals how to interface to their database system > without using the pre-processor? > The Oracle HLI is subroutine-call based; Ingres uses the embedded approach. The qualifiers to this are that I believe that Oracle now "supports" only the C language as its HLI, while Ingres does support a call interface through its OSL "4 GL". greg pavlov,fstrf, amherst, ny
jas@llama.rtech.UUCP (Jim Shankland) (08/07/87)
In article <168@bernina.UUCP> marti@ethz.UUCP (Robert Marti) writes: >The prevalent approach to offer set-oriented access to a relational >database from an application written in a langauge such as C seems >to be pre-compilation.... > >There are two drawbacks to such a solution: The first and minor one >is that such constructs look unpleasant in the source. The second >and major drawback is that a pre-processor has to written for each >new host language for which database access has to be supported.... > I would add to the list of disadvantages: it makes it hard to use existing language-sensitive tools such as syntax-directed editors, pretty-printers, call-graph generators, etc., since ESQL/C (for example) is effectively a new programming language. Add 1 major advantage: all type-checking and conversion is done automatically. The scanf-style call interface will happily read a bit pattern representing a floating point number into an integer variable; an embedded language preprocessor can do the type conversion. Finally, polymorphic functions like scanf/printf may be hard or impossible to write in some languages. Jim Shankland ..!ihnp4!cpsc6a!\ rtech!jas .!ucbvax!mtxinu!/
billc@blia.BLI.COM (Bill Coffin) (08/07/87)
In article <168@bernina.UUCP>, marti@ethz.UUCP (Robert Marti) writes: > [...] we'd much rather have an interface in the form of a library of > procedures. [ ... ] Britton-Lee Host Software supports both preprocessors and call-based interfaces. Since Britton-Lee supports transactions and views quite nicely, thank you, you might want to consider the product. On the other hand, the product involves buying a database machine. On large enough installations, this may not be much more expensive than a pure-software solution. It's worth a look. -- W.H.Coffin. billc@blia.BLI.COM (ucbvax!{mtxinu|ucsfcgl}!blia!billc) >> the usual disclaimer about my employer and my wretched opinions. << >> the usual witticisms that swell netnews to ridiculous proportions. <<
marti@ethz.UUCP (Robert Marti) (08/08/87)
In article <3209@zen.berkeley.edu>, larry@xanadu.uucp (Larry Rowe) writes in response to my previous posting: > ... the preprocessor that > you mention just translates from a ``user friendly'' notation > to an ``ugly'' subroutine call interface. ... Well, I don't think of EXEC SQL or ## markers as user-friendly, but I guess that's just a matter of taste. Speaking of a user-friendly interface from an application program to a DBMS: I really liked the idea of database programming languages such as Pascal/R, Plain, and Rigel. Unfortunately -- as we have experienced ourselves with Modula/R -- it is a pain to port these languages to other architectures, operating systems, and/or database systems. > ... > this solution assumes that the subroutine call interface can be > linked into your program. on the vax and 68K/unix this is possible > because all languages use a standard subroutine call interface. i don't > recall what machine you are using or what modula compiler you are > using, but this might present a problem. ... We are using Sun-3s running UNIX (SunOS Release 3.2, to be exact) and Sun Modula-2, Release 2.0. There are two ways to call C functions: - writing a DEFINITION MODULE FOR C whose implementation just happens to be a bunch of C functions - using the SYSTEM.CCALL procedure to directly call C functions. The first parameter to CCALL must be an ARRAY OF CHAR which contains the name of the C function. The rest of the parameters are unchecked. CCALL may either be used as procedure or as function procedure returning an INTEGER. The responses I got so far indicate that EMPRESS/32 and Sybase support call interfaces, so I'll look into it. On a final note, one drawback of call interfaces occurred to me after sending out my previous message: Most modern systems using the pre-compilation approach generate an optimized access-plan in this step. Unfortunately, I don't see an easy way to this with a call interface, so it looks as if each query (call) will have to incur the overhead of parsing the query, optimizing it and generating an access plan. It seems the best one could do is generating all access plans when starting up the application. Bob -- Robert Marti Phone: +41 1 256 52 36 Institut fur Informatik ETH Zentrum/SOT CSNET/ARPA: marti%ifi.ethz.ch@relay.cs.net CH-8092 Zurich, Switzerland UUCP: ...seismo!mcvax!ethz!marti
mickey@axis.fr (Philip Peake) (08/08/87)
In article <168@bernina.UUCP>, marti@ethz.UUCP (Robert Marti) writes: > The prevalent approach to offer set-oriented access to a relational > database from an application written in a langauge such as C seems > to be pre-compilation. ... > Since we would like to use Modula-2 to access relational databases > -- Modula-2 is the language our programmers (students) know best -- > we'd much rather have an interface in the form of a library of > procedures. ... > Oracle does supply a call interface which I assume is detailed in their documentation (if not they a do a tutorial lasting 1 (2?) days which includes course nots with sufficient detail to let you do your own). Their interface is fairly close to what you gave in your example. PS I do not work, nor have ever worked, for Oracle and no longer work for the firm that used it (and me!:) but it seems OK although SQL was an unfortunate choice (<- gratuitous opinion) Mickey Dance
garyp@cognos.uucp (Gary Puckering) (08/13/87)
In article <3209@zen.berkeley.edu> larry@xanadu.UUCP (Larry Rowe) writes: >finally, as to whether any commercial database vendors publish the >protocol between the application program and the dbms program (typically >an IPC protocol), i don't know of anyone who is doing this yet, but Both DEC and Data General publish the call-level interface to their relational database systems, namely Rdb/VMS (and Rdb/ELN) and DG/SQL. DEC's call-level interface is a DEC standard (i.e. rigidly controlled within DEC) and is known as Digital Standard Relational Interface (or DSRI). There are several third-party software products which use DSRI (including PowerHouse, Smartstar and VIDA). DG's interface is known as Host Language Interface (HLI). As for Unix products, Interbase publishes its interface (which is upward compatible with DSRI) and I believe that Sybase and Britton-Lee publish theirs too. I'd be interested in knowing if other software vendors publish their call-level interface (Oracle, Ingres, etc.). -- Gary Puckering 3755 Riverside Dr. Cognos Incorporated Ottawa, Ontario {allegra,decvax,ihnp4,linus,pyramid} (613) 738-1440 CANADA K1G 3N3 !utzoo!dciem!nrcaer!cognos!garyp