RE: Encapsulating file access in Service Programs

Regarding file update procedures..... (using native RPG file access, not
SQL)

Is the preferred method to create setter procedures for every field in
the file and have the calling program call each setter to the desired
value prior to calling the update procesure to update the record ?  Or,
should update procedures have a parm which is a data structure of the
record format for the caller to update and then call the update
procedure ?  

-----Original Message-----
From: Bartell, Aaron L. (TC) [mailto:ALBartell@xxxxxxxxxxxxxx] 
Sent: Tuesday, September 07, 2004 12:54 PM
To: RPGNext Discussion and Information
Subject: RE: [RPGNext] Encapsulating file access in Service Programs


I would rely on the composite key of the file.  Being that you are not
locking the record there is the chance there will be a different record
there when you go back.  Now if you allow them to change the unique key
values then you might have issues with that approach.

Aaron Bartell 

-----Original Message-----
From: rpgnext-bounces@xxxxxxxxxxxx [mailto:rpgnext-bounces@xxxxxxxxxxxx]

Sent: Tuesday, September 07, 2004 12:45 PM
To: RPGNext Discussion and Information
Subject: RE: [RPGNext] Encapsulating file access in Service Programs

How about using RRN.....save it on the first read and then update/delete
using the RRN ?

-----Original Message-----
From: Joel Cochran [mailto:jrc@xxxxxxxxxx]
Sent: Tuesday, September 07, 2004 8:43 AM
To: RPGNext Discussion and Information
Subject: RE: [RPGNext] Encapsulating file access in Service Programs


On Tue, 2004-09-07 at 16:43, Richard Rothe wrote:
> I don't have the luxury of using embedded SQL since we don't have SQL
> DevKit.  So, I must use native RPG I/O in my encapsulation endeavors.
> 
> What should I do to prevent record-locking ?  Should I code every
> operation no-update (N) and read the record for update when I need to 
> ? Or, do I need to not worry about record locks and be more concerned 
> about whether the record was updated by another user since the last 
> read ?

Richard,

You could have multiple files, a logical for reading, and one for
updating, writing, and deleting.  Then you just chain to the update
logical right before the update or delete.  You could also do a ton of
open-chain-close operations, but I'm pretty sure you'd take a big
performance hit, so I wouldn't recommend it.

If you wanted to verify that the record was the same as when you
initially read it, you could save the original return values into a DS,
chain again before the update, and then compare the two DS's.  In fact,
this may be a handy way to prevent unnecessary updates as well (where
none of the fields have changed).  We have an application (written when
I was still in middle school) that updates any time you hit enter on the
maintenance screen.  As such, the change dates and users are not very
useful.

BTW, I think the SQL DevKit is only about $800.  It might be worth
looking into.

Joel
http://www.rpgnext.com

_______________________________________________
This is the RPGNext Discussion and Information (RPGNext) mailing list To
post a message email: RPGNext@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpgnext
or email: RPGNext-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpgnext.

_______________________________________________
This is the RPGNext Discussion and Information (RPGNext) mailing list To
post a message email: RPGNext@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpgnext
or email: RPGNext-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpgnext.

_______________________________________________
This is the RPGNext Discussion and Information (RPGNext) mailing list To
post a message email: RPGNext@xxxxxxxxxxxx To subscribe, unsubscribe, or
change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpgnext
or email: RPGNext-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpgnext.