Re: Pro-C Question - Any Ideas?

Yes, the program is a daemon. It waits patiently for a phone call to arrive, and then jumps into action.
No, I didn't use dbx to examine the core file. If we have dbx installed, I'll check it out.

I'm only reading 3 columns (1 double and 2 chars). I initialize them before the FETCH, but no help.

Can I calloc() the sqlca area and delete() it after each phone call? Or maybe just memset() the sqlca area to NULLs each time?

Thanks for taking the time to answer.

McNaul

Ron Reidy wrote in message <3712B564.861C0480_at_uswest.net>...
>Dan,
>
>Is this program a daemon? Have you used dbx to examine the core file or
step
>through the code? You are probably correct that the core dump occurs on
>sqlcex(). What about initialization of host variables?
>
>rr
>
>Dan McNaul wrote:
>
>> Hi,
>>
>> I have a Pro-C program that runs under a flavor of UNIX. The program
>> initializes by connecting to Oracle and stays connected until the program
is
>> signaled to stop. The program does the following when a phone call
arrives.
>>
>> It creates a dynamic SQL statement.
>> It PREPAREs the SQL statement
>> It DECLARES a CURSOR for the SQL stmt
>> It OPENs the CURSOR
>> It FETCHes the rows returning the specified rows (and stores them in a
>> linked list)
>> It CLOSEs the CURSOR
>>
>> Everything works fine on the first phone call and returns the appropriate
>> information.
>>
>> On the second phone call, however, the program successfully calls
PREPARE,
>> DECLARE, and OPEN (zero sqlca.sqlcode).
>> But when the program executes the FETCH the program dumps core in the
Oracle
>> function sqlcex(). I think
>> it is related to the fact that the variables in the program still contain
>> residual data from the first phone call. I have
>> taken special care to make sure my (non-Oracle) variables are
reinitialized.
>> Have any of you seen this behavior before?
>> Does anyone have an idea of what I should do about it?
>>
>> Thanks
>>
>> McNaul
>
Received on Tue Apr 13 1999 - 06:55:35 CDT