[Info-ingres] Weird problem in Ingres 10

[Mark]

On Thu, 17 May 2018 08:05:36 -0400, Karl and Betty Schendel
<schendel at kbcomputer.com> wrote:

>Can you attach the relevant sc930 output files with a note as to what timestamp is
>the relevant one(s);  or alternatively email them to schendel at kbcomputer.com
>and I'll take a look when I get a spare moment.  (Which isn't looking too likely today,
>but tomorrow might work.)

Thanks Karl.  I have emailed you the logs.

>Karl
>
>
>> On May 17, 2018, at 7:57 AM, Mark <i at dontgetlotsofspamanymore.net> wrote:
>> 
>> On Thu, 17 May 2018 11:21:37 +0000, Martin Bowes
>> <martin.bowes at ndph.ox.ac.uk> wrote:
>> 
>>> Twice...
>>> 
>>> Once where it updates the data and once where it puts it back the way it was?
>> 
>> No.  The data is the same for each.
>> 
>>> What do the Rowcount figures say on each statement?
>> 
>> 0.
>> 
>>> Marty
>>> 
>>> -----Original Message-----
>>> From: Mark [mailto:i at dontgetlotsofspamanymore.net] 
>>> Sent: 17 May 2018 12:12
>>> To: info-ingres at lists.planetingres.org
>>> Subject: Re: [Info-ingres] Weird problem in Ingres 10
>>> 
>>> On Wed, 16 May 2018 12:40:48 -0400, Karl and Betty Schendel
>>> <schendel at kbcomputer.com> wrote:
>>> 
>>>> SC930 tracing is server wide and runs until you stop it with set notrace sc930.
>>>> So you can connect to any database, do the set trace record '/some/ingres-writable/dir'
>>>> and the set trace point sc930, go to the trace record directory you gave it and
>>>> ensure that there's at least something there (should be one or more sessNNNNN files),
>>>> and then you can run your esql program until the fault happens.
>>>> 
>>>> You don't actually need to put the sc930 into the esql program unless you want to
>>>> do it that way.
>>>> 
>>>> Once you capture what you need to capture, set notrace point sc930 turns it off.
>>>> 
>>>> You'll need the trace point privilege, simplest is to do it as the installation owner
>>>> (user ingres, traditionally).
>>> 
>>> Thanks again.  We now have traces but they don't help me.  The traces
>>> include the SQL statement and the data but, pretty much, nothing else.
>>> 
>>> The only notable thing I observed is that the data is traced twice for
>>> the failed transaction and only once for the successful ones.
>>> 
>>> There are no error messages.
>>> 
>>>> Karl
>>>> 
>>>>> On May 16, 2018, at 11:12 AM, Mark <i at dontgetlotsofspamanymore.net> wrote:
>>>>> 
>>>>> On Wed, 16 May 2018 12:11:08 +0000, Martin Bowes
>>>>> <martin.bowes at ndph.ox.ac.uk> wrote:
>>>>> 
>>>>>> Just to expand on Karl's sc930...You may already know this...
>>>>>> 
>>>>>> To turn it on, make a recording directory...mkdir /full/path/to/directory'
>>>>>> 
>>>>>> And then...
>>>>>> sql iidbdb << SQL_END
>>>>>> set trace record '/full/path/to/directory';
>>>>>> set trace point sc930 1;
>>>>>> \p\g
>>>>>> \q
>>>>>> SQL_END
>>>>> 
>>>>> Do I need to run this on the server account?  I have implemented it
>>>>> currently in the embedded SQL of my program.
>>>>> 
>>>>>> FYI. The digit after the sc930 indicates a tracing level, 1 should be sufficient.
>>>>>> 
>>>>>> Run the errant query.
>>>>>> 
>>>>>> And turn off the sc930.
>>>>>> sql iidbdb << SQL_END
>>>>>> set trace point sc930 0;
>>>>>> \p\g
>>>>>> \q
>>>>>> SQL_END
>>>>>> 
>>>>>> You can now access the recording directory and start scanning the files for any sign of life from your query.
>>>>>> 
>>>>>> Marty
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Karl and Betty Schendel [mailto:schendel at kbcomputer.com] 
>>>>>> Sent: 16 May 2018 12:54
>>>>>> To: Ingres and related product discussion forum
>>>>>> Subject: Re: [Info-ingres] Weird problem in Ingres 10
>>>>>> 
>>>>>> On May 16, 2018, at 7:44 AM, Mark <i at dontgetlotsofspamanymore.net> wrote:
>>>>>>> 
>>>>>>> On Tue, 15 May 2018 12:27:09 -0400, Karl and Betty Schendel
>>>>>>> <schendel at kbcomputer.com> wrote:
>>>>>>> 
>>>>>>>> It's certainly not something I have heard of or seen before.  Do you have any rules
>>>>>>>> defined on the relevant tables?  Try enabling LOG_TRACE if the problem is
>>>>>>>> sufficiently predictable, or do a logdump after the problem occurs if it's not;
>>>>>>>> the idea being to try to see whether you actually got any PUT (insert) or
>>>>>>>> REP (replace) log records that were then rolled back, or whether the insert / update
>>>>>>>> was never executed at all.
>>>>>>> 
>>>>>>> After enabling log_trace all I got was:
>>>>>>> 
>>>>>>>  LOG: SAVEPOINT   Size written/reserved:      0/     0  Flags:
>>>>>>> -------------------------------------------------------------------
>>>>>> 
>>>>>> So the insert/update isn't ever being executed.  Either it's failing with some sort of
>>>>>> silent error, which would seem odd, or it's not reaching the backend at all, or
>>>>>> it's being pre-empted by a before rule.  I think the next step would be to enable
>>>>>> sc930 tracing and see if the backend is getting the insert-update, and what
>>>>>> end-of-query status it's recording.  There should be KB articles on enabling
>>>>>> SC930 tracing.
>>>>>> 
>>>>>> Karl
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Info-ingres mailing list
>>>>>> Info-ingres at lists.planetingres.org
>>>>>> http://lists.planetingres.org/mailman/listinfo/info-ingres
>>>>> 
>>>>> -- 
>>>>> <insert witty sig here>
>>>>> _______________________________________________
>>>>> Info-ingres mailing list
>>>>> Info-ingres at lists.planetingres.org
>>>>> http://lists.planetingres.org/mailman/listinfo/info-ingres
>> 
>> -- 
>> <insert witty sig here>
>> _______________________________________________
>> Info-ingres mailing list
>> Info-ingres at lists.planetingres.org
>> http://lists.planetingres.org/mailman/listinfo/info-ingres

-- 
<insert witty sig here>