Re: pl plus proC

From: Michael Krolewski <mkrolew_at_pebbles.uswnvg.com>
Date: 1995/05/16
Message-ID: <3pan0g$gdj_at_fred.uswnvg.com>#1/1


cluis wrote:

: Hello world !
 

: I'm looking the way to comunicate the Oracle 4gl (or pl-sql) with
: proC in order to have an aplication comforming several modules written
: in C language and pl-SQL. Since we have the proC reference guide, it
: just treats about the "embbebed SQL within C" but I need to share
: (pass throught) parameters and functions beetween C and Oracle
: functions.
: Has anybody some reference or some knowledge about how to do this ?
: Any help would be appreciated.
 

: Thanks in advance,
 

: Carlos Luis Castillo
 

: e-mail : cluis_at_campus.mty.itesm.mx

Carlos:

        Your question is somewhat confusing.

	Assuming that you mean that the C functions that have SQL
	embedded in them are the Oracle functions, they behave like
	any other function.

	The actual oracle functions (eg EXEC SQL CONNECT, etc or the 
	OCI functions) cannot be changed in any manner like any third 
	party library. 

	The Oracle type variables in a function (between the EXEC SQL 
	DECLARE ...) are local and therefore cannot be passed. 
	If you used a global declaration (ie at the start of the file),
	these are accessible in other function/files like any other
	global.
	
	A significant issue is that since pro*C does not support
	any structure or class generation, your code must perform
	the appropriate operations to assign the SQL data to the
	appropriate fields in your structures. This goes for both
	inputs and outputs to the SQL functions.

	The general method of communicating with other 
	parts of the software is to use the SQL to collect the 
	appropriate data into some local storage.
	The simplist model is to suggest that the SQL is a 
	random access file reader. Write the C code to support
	it as such.

	open cursor	 	-->	fopen()
	fetch			--> 	read()
	close cursor		-->	fclose()

	Obviously, there is more setup, but the idea is similar.

	Read the pro*C manuals for some reference.

Mike Krolewski          Received on Tue May 16 1995 - 00:00:00 CEST

Original text of this message