× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Charles...
How is....
monitor;
write;
on-error DUPLICATE_KEY;
chain;
update;
on-error;
<other error>
endmon;

any safer (other than the last on-error) than the
chain;
if %found;
update;
else;
write;
endif;

essentially... the record would need to be added within the amount of time
that it takes to do an "if %found" check... If your machine is issuing
updates and writes in such a tight process then you would be better off
using commitment control instead of the wild west maverick database i/o
most of us IBM i programmers are used to. Which, could be mitigated just
by adding the error check inside the "if %found" like so...

chain;
if %found;
update;
on-error;
<uh oh...that was a crazy fast hijack>
else;
write;
endif;

Is it more efficient to code a monitor than to do a chain/if found? I've
never run a test, nor had I thought to until now.


Thanks
Bryce Martin
Programmer/Analyst I
570-546-4777



Charles Wilt <charles.wilt@xxxxxxxxx>
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
05/27/2011 10:53 AM
Please respond to
RPG programming on the IBM i / System i <rpg400-l@xxxxxxxxxxxx>


To
"RPG programming on the IBM i / System i" <rpg400-l@xxxxxxxxxxxx>
cc

Subject
Re: Embedded SQL - performance question






Depends on your idea of sense :)

If you normally expect the record not to be there...
monitor;
write;
on-error DUPLICATE_KEY;
chain;
update;
on-error;
<other error>
endmon;

Is best from a performance standpoint...

The problem with this code
chain;
if %found;
update;
else;
write;
endif;

Is that the chain and the write are not atomic....you leave yourself
open to the record being added by some other process between the chain
and the write...what you'd really need would be

chain;
if %found;
update;
else;
monitor;
write;
on-error DUPLICATE_KEY;
chain;
update;
on-error;
<other error>
endmon;


Charles
endif;


On Fri, May 27, 2011 at 10:04 AM, Schutte, Michael D
<Michael_Schutte@xxxxxxxxxxxx> wrote:
Yes this is odd.

I don't like it myself.

Would have made more since to chain, update when found, insert when not
found.

JMO

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx [
mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Elbert Cook
Sent: Thursday, May 26, 2011 5:47 PM
To: 'RPG programming on the IBM i / System i'
Subject: RE: Embedded SQL - performance question

Sorry off topic.

I saw this piece of code on our system yesterday. I'm still not sure
what to
think.

Exec Sql Insert Into myLib/myFile (Pattern, Color, Onhand)
VALUES(:Pattern1,
:Color1, :Qty1);

IF SQLCOD = -803;
Chain (Pattern1: Color1) myFile;
IF %found;
Onhand = Qty1;
Update myFilef %fields(Onhand);
Endif;
Endif;


-----Original Message-----
From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
Sent: Thursday, May 26, 2011 5:13 PM
To: RPG programming on the IBM i / System i
Subject: Re: Embedded SQL - performance question

On 5/26/2011 3:16 PM, CRPence wrote:

I expect that SQL should be much faster even on a poorly performing
system; almost as fast as the RLA, esp. if the same index is utilized
for both the SQL and RLA.

I've never found a single-record fetch to be anywhere near as fast as
RLA, and I did exhaustive tests; SQL doesn't catch up until the block
size is upped to about 100 records. I could rerun all those tests, but
until someone shows me some evidence SQL has caught up, I have no reason
to repudiate the old data.

Joe
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.

________________________________

Notice from Bob Evans Farms, Inc: This e-mail message, including any
attachments, may contain confidential information that is intended only
for the person or entity to which it is addressed. Any unauthorized
review, use, disclosure or distribution is strictly prohibited. If you are
not the intended recipient, please contact the sender by reply e-mail and
destroy all copies of the original message and any attachments.
--
This is the RPG programming on the IBM i / System i (RPG400-L) mailing
list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.