Very Computer

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.

Thanks

--
David

Pro-C and Pro-Cobol are pre-compilers that generate legal C or Cobol code
from C or Cobol code that contains embedded SQL statements.  The pre-compiler
takes the embedded SQL, which is usually in the following form:
...
exeqsql "select * from table_name where ...  "
...

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.

Rich

Quote:

>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.

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
Keith

To expand a little bit on Keith's very nice summary of precompilers;
there are three ways that a 3GL language like C, Ada, or Cobol can be
used to access a database server:

APIs
Precompilers
Module Language

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
very complicated.

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;
char emp_name[20];
int  emp_number;
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),
              emp_number INTEGER,
              SQLSTATE);
     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
standard.

This barely scratches the surface. If anyone would like additional
direction, feel free to e-mail.

Rdb offers module language, yes. And Oracle is the vendor nowadays.

/per

--

SEB Data, R-E4
S-106 40 Stockholm
Sweden