Pro*C



  • Did anyone ever use ProC?

    This was Oracle's attempt at integrating SQL with C.  Rather than providing something like a class library, they decided that using libraries was far too hard for average programmers.  So what did they provide? 

    A preprocessor!

    http://www-db.stanford.edu/~ullman/fcdb/oracle/or-proc.html

    So scattered around your C code would be sections like....

            int a;
            /
    ... /
            EXEC SQL SELECT salary INTO :a
                     FROM Employee
                     WHERE SSN=876543210;
            /
    ... /
            printf("The salary is %d\n", a);
            /
    ... /

    That's right! You've got code with completely different scoping rules, different types, and crazy syntax, embedded right in your C code!  In addition, who knows what actual C code is being generated by this preprocessor.

    So now you have C programmers, who know crap about databases and have no idea how to actually structure efficient queries.  You have a preprocessor that generates unknown calls to the SQL library, and you have the perfomance of Oracle.

    Hello trainwreck.

    Oh, and I had to use this on a VAX.  In 1998. 

    Thankfully it was only for a simple school project.   I shudder to think of this tool being used in production environment.  I read somewhere that the popular thing to do was ignore Pro
    C and just use the library that it linked against directly.



  • As a matter of fact, I don't think this idea was an Oracle one.  Many DB engines used to provide this type of preprocessor.  The general concept is known as "Embedded SQL".  I've seen very-VERY old programs running against DB2 on mainframe that use this concept.

    IMO, Pro*C was oracle's product to allow them to compete with DB2 on the mainframe and mini market.

    Kelly



  • I do think it's nice if you can just insert SQL commands like this in your code. Then again, I think C by itself is a true WTF anyway. Pascal is so much easier and about as powerful...



  • I think C by itself is a true WTF anyway. Pascal is so much easier and about as powerful...

    Are you kidding. Pascal is one step towards Foxpro, There is noooooooooo way pascal is better than C.



    C is supposed to be one level higher to Assembler. If you C is bad.
    then you should try doing that in Assembly, then you will realise how C
    lang is good and close to Assembler.



    Pascal is way out of line, bound check, yada yada yada









  • Betreft: Re: Pro*C

    Pascal is about as close to Assember as C is. And to be honest, the old
    GWBasic was also pretty close to assembler, although it didn't compile
    but was interpreted. (And the Basic versions that did include a
    compiler just compiled to some pseudocode that needed an additional
    runtime library.)

    If you do compare Pascal with C then you will notice that they have a
    very close performance. But the strict syntax of Pascal will make it
    harder for you to include any bugs in your application. :) C will be a
    bit faster with it's string-handling but in other aspects, they won't
    have much performance difference.



  • @XPav said:

    Did anyone ever use ProC?

    This was Oracle's attempt at integrating SQL with C.  Rather than providing something like a class library, they decided that using libraries was far too hard for average programmers.  So what did they provide? 

    A preprocessor!



    Boy, you can always use the OCI (Oracle Call Interface) if Pro
    C is too little of a challenge for you.
    Though Pro*C offers some WTFs (like not understanding all C constructs, complaining about certain perfectly valid include files) it makes database programming with C by far much easier.


    In addition, who knows what actual C code is being generated by this preprocessor.


    Ugly, almost unreadable code. Just look at foobar.c generated from foobar.pc.




  • @XPav said:

    Did anyone ever use Pro*C?


    Me, along with Visual C 1.0 on Windows 3.1, do I get a prize?



  • I've just got off a project where I did lots of Proc programming....
    I've also come across a few bugs in pro
    c during that time, for instance, in bulk uploads, I had the date as a global variable, and the rest of the data in an array of structs. This would throw an error though, something about the date not being valid (not alway though, and usually at around the commit size). To fix it? Had to move the date into the structure...



  • It's not a bad idea in principle (you get compile-time checks for your SQL queries), if only it worked well! I'm using ProC now and boy what a piece of junk it is. The biggest WTF:


    #if 0
    # define blah(...)
    #endif

    It craps out at #define (==> inside #if 0 <==), unable to parse C'99-style vararg macros.



  • @let said:

    It's not a bad idea in principle (you get compile-time checks for your SQL queries), if only it worked well! I'm using ProC now and boy what a piece of junk it is. The biggest WTF:


    #if 0
    # define blah(...)
    #endif

    It craps out at #define (==> inside #if 0 <==), unable to parse C'99-style vararg macros.

    My way around the stupidity of ProC goes like that:

    In the .pc file:

    #ifndef STUPID_PROC
    /* stuff that ProC doesn't like /
    #include <stdio.h>
    #include <math.h>
    /
    ... /
    #else
    /
    a few dummy prototypes so ProC is happy */
    extern double rint(double);
    extern void *calloc(int,int);
    extern void *stderr;
    #end if

    In the makefile:

    foobar.o: foobar.pc
        proc user=foo/bar@$(SID) oname=foobar.c sqlcheck=semantics $? define=STUPID_PROC
        gcc -c -g foobar.c
     

     

     



  • Yup, the idea of "embedded SQL" always scared me. I learned it at school ( '99 ... ) and indeed I felt it wrong : high-level language ( SQL ) embedded within portable assembly language. The very purpose of both worlds fighting against each other. This had to be a sense quite long ago ( I mean, 10 years ago at least ), but nowadays it's like running 10 miles wearing wooden dutch sabots. And a kilt. Playing bagpipes.

    Other WTF fact is we learned at the same time, as an higher-level language accessing databases, ... *tada.wav* ... powerbuilder. Hey, don't run away like that, you're not going far with these wooden shoes.

    Then again, I had my first job. Guess what we had to face. C cgis with informix embedded SQL. Hey, be fair, don't roll on the floor like that, this can't be such a bad choice at the time of its deployment. Our job was to port it to more manageable templated PHP. No more tedious compilation and the like ... in fact the WTF that followed is that it was so easy to modify and deploy that people get used to 0-day patch, and here goes the cowboy coders. He, that's still the world we live in now, and it doesn't look like it's going to change.



  • Try setting the ProC PARSE option to PARTIAL or NONE. It makes the precompiler a lot easier to live with.

     
    http://download-west.oracle.com/docs/cd/B19306_01/appdev.102/b14407/pc_12cpl.htm#i864 talks about the values you can have and the impact of the settings for this option.


  • @prakash said:

    C is supposed to be one level higher to Assembler. If you C is bad. then you should try doing that in Assembly,

    EXEC SQL SELECT salary INTO [ebp-12] ... hmm, this isn't so bad



  • Err, LINQ anyone?


Log in to reply