[Info-ingres] Weird problem in Ingres 10

[Martin Bowes]

No error code and with a rowcount of zero means the update is successful, but had no work to do.

I presume there is a where clause in the update and that it looks OK.

Can you compare the code which worked and the code which didn't work for discrepancies?

Marty

-----Original Message-----
From: Mark [mailto:i at dontgetlotsofspamanymore.net] 
Sent: 17 May 2018 12:57
To: info-ingres at lists.planetingres.org
Subject: Re: [Info-ingres] Weird problem in Ingres 10

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