Re: Basic PRO*C problem

From: Kenneth C Stahl <BluesSax_at_Unforgettable.com>
Date: Wed, 18 Aug 1999 09:17:41 -0400
Message-ID: <37BAB274.AC2F612E_at_Unforgettable.com>


[Quoted] I'm not so sure that it is a good idea to just abandon Pro-C. First of all, with Oracle V7.3 and higher Pro-C++ is available and using dynamic sql version 4 it would be possible to encapsulate/abstract the various constructs needed to log into oracle and perform work. I actually wonder why Oracle hasn't come up with something like this on their own to keep the business in-house rather than waiting for third-party vendors to do this development.

Ken
"Rodrigo Valladares P." wrote:

> I suggest you to abbandon PRO*C, and with a little of effort (at the
> beggining), do the same in c++, in a more civilized manner. I have been
> working around 3 year in a *big* proyect for a telecommunication company, it
> started in PRO*C, but as soon the proyect grew, we must do the migration to
> c++. Specifically, PRO*C is a precompiler, it doesn't know what is
> sorrounding the code, and some options remains active after you exit from
> the scope of your function. And deal with errors is traumatic experience.
> Porting your software to c++, using OCI (Oracle Call Interface) encapsuled
> under classes to hide the (ugly!) semantic of it, and use exceptions to
> manage all the errors of OCI make the life easy!. Relative to the
> performance, we work with 10*meg's of recors monthly, and we dont have a
> noticeable change in performance.
>
> In a matter of example, consider the folowing:
>
> dbConnection conn("scot", "tiger");
>
> dbQuery q(conn, "select user_id, password, action, "
> "from user_profiles_changes where status=0");
>
> while(q.Next())
> {
> printf("%s\t%s\t%s\t\n", q["user_id"].AsString(),
> q["password"].AsString(), q["action"].AsString());
> }
>
> //
> // close and disconnection for free, in the destructors !
> //
>
> Kenneth C Stahl escribió en mensaje <37B80262.77284659_at_Unforgettable.com>...
> >I notice that you are not using indicator variables. If the version of the
> >RDBMS is 7.3 or higher you need to have indicator variables.
> >
> >Ken
> >
> >Patrick Drouin wrote:
> >
> >> PRO*C is driving me crasy. I am trying to compile a VERY SIMPLE program
> >> that uses a cursor. I've done it in the past and ran into problem but
> >> moving some code around fixed it (don't ask why!). Now, it just won't
> >> budge.
> >> PRO*C compiles the C file without any problems but gcc or the Sun
> >> compiler will not accept the generated code (I would do the same...).
> >> Here's the snippet of my code. Anything wrong with this?
> >> /* We query the USER_PROFILES_CHANGES table */
> >> /* and grab all the entries. The ACTION column */
> >> /* tells us what to do and the status tells us */
> >> /* which rows we need to process. */
> >> EXEC SQL DECLARE user_list CURSOR FOR
> >> SELECT user_id, password, action
> >> FROM USER_PROFILES_CHANGES
> >> WHERE status=0;
> >> /* Open the cursor we have prepared */
> >> EXEC SQL OPEN user_list;
> >> /* Loop on the cursor and break if empty */
> >> EXEC SQL WHENEVER NOT FOUND DO break;
> >> for(;;){
> >> /* Fetch values into our HOST variables */
> >> EXEC SQL FETCH user_list INTO :new_user, :new_user_password,
> >> :action;
> >> printf("%s\t%s\t%s\n",new_user,new_user_password,action);
> >> }
> >> /* Close the cursor */
> >> EXEC SQL CLOSE user_list;
> >>
> >































Received on Wed Aug 18 1999 - 15:17:41 CEST

Original text of this message