Re: Basic PRO*C problem

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 - 00:57:33 CDT