Re: To the moderator

Kaz Kylheku wrote:
>
> In article <353F8A87.1CD0BA96_at_fairway.com>,
> Jeffery Cann <jcann_at_fairway.com> wrote:
> >> You can't do embedded SQL in C and still call it C. So your question has
> >> nothing to do with the C language.
> >
> >Really? Then why does my processed ESQLC code "look and feel" like C.
>
> The syntax of C isn't defined by look and feel.

That was a joking remark, hence the smiley face.

> ESQLC isn't C, it's a language based on C.

Granted, the point is that ESQLC is precompiled into C function calls and assignments. This code is then compiled by a C compiler and linked into an executable with other C objects and libraries. This sure seems like C to me.

For example:

	/* Here is an ESQLC statement */
	/* Sent to the precompiler */
	EXEC SQL
		SELECT RESERVATIONS_SEQ.NEXTVAL
		INTO :reservation2:ind1
		FROM DUAL;

	/* Here is the C code that the precompiler */
	/* generated from the above ESQLC code     */
	{
		struct sqlexd sqlstm;

		sqlstm.sqlvsn = 8;
		sqlstm.arrsiz = 2;
		sqlstm.stmt = "select RESERVATIONS_SEQ.nextval  into :b0:b1  from DUAL
";
		sqlstm.iters = (unsigned int  )1;
		sqlstm.offset = (unsigned int  )24;
		sqlstm.selerr = (unsigned short)1;
		sqlstm.cud = sqlcud0;
		sqlstm.sqlest = (unsigned char  *)&sqlca;
		sqlstm.sqlety = (unsigned short)0;
		sqlstm.sqhstv[0] = (unsigned char  *)&reservation2;
		sqlstm.sqhstl[0] = (unsigned int  )4;
		sqlstm.sqindv[0] = (         short *)&ind1;
		sqlstm.sqharm[0] = (unsigned int  )0;
		sqlstm.sqphsv = sqlstm.sqhstv;
		sqlstm.sqphsl = sqlstm.sqhstl;
		sqlstm.sqpind = sqlstm.sqindv;
		sqlstm.sqparm = sqlstm.sqharm;
		sqlstm.sqparc = sqlstm.sqharc;
		sqlcxt((void **)0, &sqlctx, &sqlstm, &sqlfpn);
		if (sqlca.sqlcode < 0) goto sql_error;
	}
 

> Why don't we admit C++ questions too? After all, there exists CFRONT,
> which translates C++ into C. Then there are f2c and p2c, so
> Fortran and Pascal are on topic as well! Eiffel, anyone?

I agree that any Oracle questions concerning Pro*C are best left in comp.databases.oracle.tools or comp.databases.oracle.misc. My point is that the Pro*C precompiler generations C code.

> >The ESQL is translated into Oracle C library calls. Granted, the
>
> Translated by something other than a C implementation, into an undoubtedly
> platform-specific C program which relies on features that aren't part
> of the language.

In fact, it is platform independent, because the platform code is abstracted by the calls to the Oracle libraries. Oracle handles the platform-specific issues. Now, you would have to re-precompile a pro*c file if you move it from one platform to the other, so if your definition of platform-dependant falls here, then fine.

> >Oracle-generated code as some strange usage, but it is still C. It even
> >can generate ANSI C.
>
> I doubt it, since it most likely relies on libraries that are not part of ANSI
> C which enable it to communicate with the database system.

This may not be the case. We would have to see exactly what the code in these libraries looks like. In addition, I am fairly certain that the Oracle libraries are written in C and are using the C standard library, unless Oracle decided to write their own libraries to replace the standard C library. This doesn't seem particulary pragmatic, given the cost of producing (i.e., duplicating) the standard C library.

> Any question about such libraries would not be topical for comp.lang.c.

Here's where we diverge.

> What you probably mean is that the tool will generate C which uses function
> prototypes.

Yes, that is what I meant.

The other point I want to make is that unfortunately for people who work on applications that contain ESQLC, the comp.databases.oracle.tools and comp.databases.oracle.misc does not have 1/10th the experience in coding C that comp.lang.c readers do. If they do have more experience, the postings don't show it.

I suspect that the experienced C programmers who work with Oracle don't read any oracle newsgroups, only comp.lang.c. I suspect this because I once posted a question about unsigned chars in oracle structures to comp.lang.c and recieved numerous replies.

In addition, the majority of the questions in these oracle groups are about Developer/2000 (GUI forms toolkit), not Pro*C.

So, as a newsgroup poster, you have 2 options: 1) post to comp.lang.c and usually get an coherent answer from someone who does not read comp.databases.oracle.tools 2) post to comp.oracle.blah.blah and get virtually no respose (with regard to pro*c questions).

In fact, this dual thread is the most discussion I have seen about pro*c in comp.databases.oracle.misc since I started reading it 4 months ago (and its a whopping dozen or so messages).

Jeff

-- 
Jeffery Cann
Fairway Systems, Inc.
Senior Software Engineer