Re: To the moderator

Lawrence Kirby wrote:
>
> In article <353FCB04.B87CD05C_at_fairway.com>
> jcann_at_fairway.com "Jeffery Cann" writes:
>

[snip]

> >> >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.
The fact that a program utilises libraries other than the standard one does not mean that it is not a ANSI C program. After all the standard library may well use functions from a platform specific library its self. It may not be portable but that is not the same thing.
> >
> >This may not be the case. We would have to see exactly what the code in
> >these libraries looks like.
>
> Take sqlcxt() above.It isn't a standard C library function. No truely
> portable C code can call it unless *you* have as part of the program portable
> source code for sqlcxt(). If you don't have the source code then whether
> sqlcxt() is originally written in portable code or not is not relevant since
> you don't have the means to port it.

The only plaforms that such a program can be supported is one that is supported by Oracle. Since on Oracle supported platforms the PRO*C translator will produce this code and provide the libraries containing sqlcxt or it equivilents there is no need to port it one self.
>
> >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.
>
> I doubt whether the Oracle libraries could be written entirely in terms
> of the standard C library. The problem is that that doesn't provide
> any locking or other means to create serialisation mechanisms. Also
> performance tends to be mportant for databases so commercial DBMSs tend to
> make use of whatever platform-specific magic is available to squeeze out
> that last bit of performance.

The Oracle libraries do utilise the standard library. Locking and so forth are a feature of the database server and not the client program and therefore not relevent. However the communication between client and server, which can be done in a number of ways, will as you say undoubtably use some platform specific approach. [snip]

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

Try comp.database.oracle and comp.databases.oracle you will find that the range of questions and experience much wider that the two groups that you mention.
>
> >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.
>

How many would you have received if you had posted it to an oracle group?

> >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
ditto above

The process of compiling a PRO*C program involves the pre-processing of the PRO*C with some C pre-processing included within it, the normal C pre-processing followed by the C compilation. The interaction between these stages often mean that errors do not appear until the final stage. The programmer is than faced with the question of whether the cause of the error lies in the C code that they have written or the C code that was generated. Under these circumstances looking at the generated C output is often the best way to locate the error and then back tracking to the actual cause.

Herein lies the problem that we have seen here. If you can't locate the error and need advice who do you turn to? Is it a C problem or a PRO*C problem? It must be said that PRO*C does really try hard to produce ugly code and this is likely to offend most C programmers but unfortunatly it also confuses the less experienced even more.

I would suggest that most of the time that the comp.database.oracle and comp.databases.oracle NGs are a good _first_ port of call rather than the more specific Oracle ones.

Steve

But a tip for inexperienced PRO*C programmers. Analyse how the PRO*C compiler produces C code and many of the common mistakes are easily resolved. If you leave this analysis until you have a problem you should be suprised if you find the going tough.

Steve Received on Tue Apr 28 1998 - 00:00:00 CDT