NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/database/ingres/1190

Text File | 1992-08-20 | 3.1 KB | 72 lines

Newsgroups: comp.databases.ingres
Path: sparky!uunet!sun-barr!sh.wide!wnoc-tyo-news!nec-tyo!nec-gw!mips!sdd.hp.com!wupost!gumby!destroyer!ncar!uchinews!gsbacd.uchicago.edu!cs_mj
From: [e-mail] (Mark Jaeger)
Subject: Re: ESQL Bug
Message-ID: <[e-mail]>
Lines: 60
Sender: [e-mail] (News System)
Organization:
References: <[e-mail]>
Date: Thu, 20 Aug 1992 21:24:13 GMT

In article <[e-mail]>,
[e-mail] writes:

> I wrote an embedded SQL program using C that seems to go into an
> infinite loop when I have too many records to process, and
> I can't figure out why.  The program simply sets up a
> cursor to read each record, take a character field (storing
> a gregorian date) and convert it to a date.  It updates another
> field in the same record (a date field), and fetches the next record.
>
> This seems easy enough, but if my table gets too large it seems
> to get "stuck" on a record and processes that same record until I
> stop the process.  The strange thing is, depending on the Ingres
> installation (production vs development) the program will run longer
> before looping.  (The production machine can handle larger tables
> than the development.)
>
> Our current work around for the problem is to chop the table into
> smaller bits.  This seems to work, but I'd love to know what the
> real problem is.  Ingres never gives us an SQL error or VMS
> error message to track so we have decided it is not in our code
> or data.

A guess: maybe your transaction log file is filling up.  A cursor has to
be run inside a transaction, and if you are updating each row after you
read it in, then INGRES has to log your entire table (before image and
after image pages) to the INGRES transaction log file before you commit
the transaction.

This diagnosis is not entirely consistent with your symptoms, however,
because you state that you get no error message from INGRES.  When your
program starts looping, try looking at the end of ii_config:errlog.log
to see if it shows log file full.  Also, use "show process/continuous"
to look at the front end, the dbms server, and the recovery process
(DMFRCPxx or II_RCPxx) to see which one is active.  This may give a clue
to where things are stuck.

Are you doing error checking in your C program?  Are you sure that your
cursor "fetch" loop terminates on any error, or are you just looking for
the "no rows found" condition?  Try adding these lines at the beginning
of your C program:

    exec sql WHENEVER sqlerror call sqlprint ;
    exec sql WHENEVER sqlwarning call sqlprint ;

You could also try running your program after doing this:

    $ define ii_embed_set "printgca"

and looking at the file "iiprtgca.log" that gets created.  It may
provide a clue to where front-end/back-end communication breaks down.

Hope this helps.

--Mark Jaeger                internet: [e-mail]
Graduate School of Business        yellnet:  [phone]
University of Chicago            faxnet:   [phone]
Disclaimer: My opinions are my own and not those of my employer.
Ich bin ein Virus.  Mach' mit und kopiere mich in Deine .signature.