"revdberr, " as the returned value on *successful* postgres operations

[Mike Bonner]

Is it reliably reproducible?  You said:  "I've also seen the same issue
with single transactions outside of BEGIN
blocks."
When using the same data, same single transaction, do you get the same
result every time?  Does changing the data change the response?  If a
specific set of conditions can be tracked down that cause the issue it
would be a huge step towards a solve.

Also i'm wondering, if you make the changes, do the commit,
then immediately select the same records, have they all been successfully
updated?  I don't know enough about how postges works to be sure but either
a)  (ignoring the fact that single statements sometimes do this) if a
begin/commit block has a problem with a statement, then postgres may treat
it as an atomic transaction (1 fails all fail) and autorollback, or b) its
informing you that there was an issue in there somewhere and giving you the
option to rollback yourself.

You might, short term, remove the begin/commit, and use a repeat to loop
through each sql statement, logging the sql used for each, the values being
passed in, and whether or not there was an error. Even if you do this one
single time, if you get a viewable error, its worth the time involved. And
if you don't, that might be informative too.  If there are LOTS of
transactions to be done this will be considerably slower, but may be
necessary.

Sorry, was typing and thinking as you were answering.  Yeah, it
will CONSIDERABLY slow down your transactions to use the 1 at a time
method, but if you can do it with a small dataset to track down the issue
it might be worth it.  My worry would be that there is actually a real
reason you're getting this error rather than a strange glitchy thingy that
can be safely ignored.


On Tue, May 14, 2013 at 11:11 AM, Mike Bonner <bonnmike at gmail.com> wrote:

> Right, if you're using a transaction block then yes you need the
> intermediate semicolons added yourself. (unless you're using multiple
> separate revexecutesql statements rather than handing off a complete list
> in 1 go)
>
> So yeah if you do
>
> revexecutesql with your begin transaction
>
> a repeat with a revexecutesql for each command to use
>
>
> and a revexecutesql with a commit after the repeat then no semicolons
> should be added. Since you're building the whole thing and then sending it
> as a unit, all but the last would be needed as you surmise.
>
> I was just going based on the code you posted previously so was unsure of
> your method.
>
>
>
>
>
> On Tue, May 14, 2013 at 11:03 AM, Dr. Hawkins <dochawk at gmail.com> wrote:
>
>> On Mon, May 13, 2013 at 7:11 PM, Mike Bonner <bonnmike at gmail.com> wrote:
>>
>> > Are you adding the ; at the end of your sql strings?  I'm pretty sure
>> rev
>> > appends its own ; so the result would be an extra one. Which might make
>> > postgres a) do whatever you told it to, then b) return a confused error
>> due
>> > to the second ;
>> >
>> > Try it without adding the ;
>> >
>>
>> I took off the trailing semicolon:
>>
>> BEGIN TRANSACTION;
>> UPDATE  baggins_bilbo____001_sofa SET A = 'Ape guy', B = 'Sunday', C = '9
>> banana', D = '', usr= '', tstmp = NOW() WHERE uniq_sfky =7;
>> UPDATE dhbk_dtIdx SET lastOpened=NOW(), usr=' ' WHERE
>> dtStem='baggins_bilbo____001';
>> COMMIT
>>
>>  and still get the same message.
>>
>> Livecode certainly isn't adding semicolon after every line--if I take out
>> the others, the UPDATE throws an error.
>>
>> I've also seen the same issue with single transactions outside of BEGIN
>> blocks.
>>
>>
>> --
>> Dr. Richard E. Hawkins, Esq.
>> (702) 508-8462
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at lists.runrev.com
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>>
>
>