Could anyone inform me as to what these two languages are and how they
relate to ORACLE database systems development. Also how do they differ from
'c' and COBOL.
and replaces it with a series of legal C or Cobol procedure calls to an
API supplied by Oracle.
The legal code can then be compiled by your favorite C or Cobol compiler.
C and Cobol compilers in their natural habitat do not know anythingQuote:
>Could anyone inform me as to what these two languages are and how they
>relate to ORACLE database systems development. Also how do they differ from
>'c' and COBOL.
In order for us to be able to write programs in these languages,
database vendors produce products called pre-compilers. Pre-compilers
allow us to put database calls in our source code using the
database's native syntax.
Using a pre-compiler, the compilation process is a two step affair:
1. The pre-compile.
Your original source code file (containing the 'select * from
customer' command) is used as input to the precompiler. The
output from the pre-compiler is a temporary source code file with
the database commands replaced by commands in the 'host' language's
syntax. These replacement commands can be *very* complex.
2. The compile.
The temporary source code file is then submitted to your
compiler and the executable is created.
Pro*C and Pro*Cobol are Oracle Corp's pre-compilers for C and Cobol,
respectively. As such, they are not 'languages' in their own right.
They simply allow us to put Oracle calls in C or Cobol programs.
Hope this helps
>>Could anyone inform me as to what these two languages are and how they
>>relate to ORACLE database systems development. Also how do they differ from
>>'c' and COBOL.
>C and Cobol compilers in their natural habitat do not know anything
>about accessing an Oracle database. Try including the statement
>'select * from customer' in a source code file and compiling it and
>you'll see what I mean. This is true for other databases as well.
An API (Oracle's is called the OCI) lets you call functions in a
runtime library that perform basic DB operations. To process a SQL
statement, you have to parse the statement, bind addresses of program
variables to parts of the SQL statement, and then execute the
statement. If the statement is a SELECT (query), you then have to
fetch the data into bound program variables. Very flexible, but also
Consider the SQL statement
SELECT ename FROM emp WHERE empno = :number
For this statement, you have to supply (or bind) program variables
that hold the output (ename) and the input (:number).
A precompiler is much simpler. With a precompiler, you simply include
the SQL statement in your 3GL program, and let the precompiler take
care of all the parsing, binding, executing, and fetching for you. For
example, to process the statement above in a C program, all you have
to do is declare the host variables for input and output:
EXEC SQL BEGIN DECLARE SECTION;
EXEC SQL END DECLARE SECTION;
and then embed the SQL statement directly into your program:
emp_number = 7499;
EXEC SQL SELECT ename INTO :emp_name FROM emp WHERE empno = :emp_number;
Notice that the syntax of the embedded SQL statement changes slightly:
there is an INTO clause in the SELECT statement, that you don't need
with interactive SQL, or with an API. (This is all very standardized,
and ANSI/ISO have defined the syntax of embedded SQL very
rigorously. The Oracle precompilers adhere to these standards.) When
you include embedded SQL (EXEC SQL ...) stuff in your C or Ada (or
Fortran, or Cobol, or Pascal, etc.) code, you must pass the code through
a precompiler, that changes the SQL statements into data structures
and calls to a runtime library (SQLLIB in the Oracle case) that
handles the SQL.
Then why, the reader might ask, would anyone want to use an API over a
precompiler (embedded SQL)? One answer is that there are some
complicated things that you can do in SQL statements, that can be
handled by both interfaces, but that are just as complicated using
both. Consider the statement
SELECT * FROM some_table
where you do not know how many columns occur in "some_table", and do
not know the datatypes of these columns. You can process this kind of
statement using either an API or a precompiler, but you have do some
extra work with the precompiler that you didn't have to do with the
simpler SELECT ename ... statement used earlier.
The third way of interacting with a DB using a 3GL language is Module
Language. In this case, you put your SQL statements in a separate
file, and "parameterize" them. So the SELECT ename ... statement
above becomes a procedure:
get_emp_name (emp_name CHAR(20),
SELECT ename INTO :emp_name FROM emp WHERE empno = :emp_number;
in a module file, which is then processed by a Module Language
compiler into a set of data structures and calls to a runtime
library. In the host program, you call the function get_emp_name() at
application runtime, supplying the input emp_number parameter, and
getting back the output emp_name parameter, as well as a possible
error indicator (SQLSTATE). The advantage of this approach is that you
can separate out the embedded SQL from the 3GL code, which can, among
other things, make debugging a lot easier.
I don't know how many vendors offer Module Language. Oracle does (for
C, C++, and Ada), and DEC at least used to with Rdb. It is an ANSI/ISO
This barely scratches the surface. If anyone would like additional
direction, feel free to e-mail.
> This barely scratches the surface. If anyone would like additional
> direction, feel free to e-mail.
SEB Data, R-E4
S-106 40 Stockholm
Can some one tell me which UNIX Cobol Compilers will work with Oracle's
And which MS-DOS Cobol Compilers will work with Pro-Cobol?
(404) 840-9200 (x.2131) | uucp: uunet!hayes!alacy
Hayes Microcomputer Products | U.S.Mail: p.o.box 105203, Atlanta, GA 30348