RE: ALL I/O in single module was(ARGH!!! (was file open with LR))

That's a concern.  The problem is that many writers of trigger programs 
tend to 'ass-u-me' that all executions of the trigger are going to come 
from the same 5250 program they were doing maintenance from in the first 
place.  Thus they tailor it to interact only in that environment.  Like 
certain methods of message handling.  However if you do something generic 
like send an escape message then it will be the job of whatever program 
that did the update to trap for that.  And this should be able to occur 
regardless of your environment:  custom 5250, UPDDTA, odbc, JSP's, etc.

I truly believe that this is what was being addressed in the article you 
quote.

Rob Berendt
-- 
"They that can give up essential liberty to obtain a little temporary 
safety deserve neither liberty nor safety." 
Benjamin Franklin 




Jake Bruster <jakebruster@xxxxxxxxx> 
Sent by: rpg400-l-bounces@xxxxxxxxxxxx
11/17/2003 10:25 AM
Please respond to
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>


To
RPG programming on the AS400 / iSeries <rpg400-l@xxxxxxxxxxxx>
cc

Subject
RE: ALL I/O in single module was(ARGH!!! (was file open with LR))






Rob, 

I tend to agree with the idea that data validation
should be implemented in the database itself using
constraints but I found this compelling arguement
against using triggers for data validation. It comes
from an article in iSeries News by Sharon Hoffman
(www.iseriesnetwork.com Article ID 15002).

Although many people use trigger programs for data
validation, there are drawbacks to this approach. When
you use a trigger for data validation, any application
that might launch the trigger must be able to handle
errors generated by the trigger program. This is
contrary to the essential philosophy of triggers,
which assumes that a trigger may be launched from any
application and that the application writer may not
even be aware that a trigger is associated with a
particular database event. 

Regards,
Jake
 
--- rob@xxxxxxxxx wrote:
> Booth,
> 
> I agree with validity checking in one place. 
> However I disagree about an 
> I/O module for it.  The validity checking could be
> in proper setup of the 
> database.  For instance with constraints and/or
> triggers then any updates 
> done with any tool are checked.  And there is NO
> leak from someone who 
> accessed the file without using the I/O module.
> 
> Rob Berendt
> -- 
> "They that can give up essential liberty to obtain a
> little temporary 
> safety deserve neither liberty nor safety." 
> Benjamin Franklin 
> 
> 
> 
> 
> "Booth Martin" <Booth@xxxxxxxxxxxx> 
> Sent by: rpg400-l-bounces@xxxxxxxxxxxx
> 11/14/2003 04:47 PM
> Please respond to
> RPG programming on the AS400 / iSeries
> <rpg400-l@xxxxxxxxxxxx>
> 
> 
> To
> <rpg400-l@xxxxxxxxxxxx>
> cc
> 
> Subject
> RE: ALL I/O in single module was(ARGH!!! (was file
> open with LR))
> 
> 
> 
> 
> 
> 
> The benefit of having all validity checking in one
> place seems like a big
> win to me, especially when one begins to deal with
> data updates from 
> places
> other than the green screen.
> 
> 
>
---------------------------------------------------------
> Booth Martin   http://www.MartinVT.com
> Booth@xxxxxxxxxxxx
>
---------------------------------------------------------
> 
> -------Original Message-------
> 
> From: RPG programming on the AS400 / iSeries
> Date: 11/14/03 15:13:09
> To: RPG programming on the AS400 / iSeries
> Subject: RE: ALL I/O in single module was(ARGH!!!
> (was file open with LR))
> 
> >   This, by
> >the way, is another reason that I advocate moving
> ALL file I/O for a
> >file into a single module; it avoids some of these
> issues.  It sometimes
> >causes a little extra upfront work, but in the end
> it makes your life a
> >lot cleaner.
> 
> I've been coding RPG since '84, so I'm somewhat of a
> dinosaur in this 
> regard
> 
> 
> I haven't been convinced (yet!) that it's better to
> have the file I/O in
> one module.  With the existing code, I can look at
> the F specs and see 
> what
> gets read and/or updated.  I can scan for CALL and
> see any programs that
> might also update a file.
> 
> With procedures, the code is much more intertwined,
> and it doesn't seem as
> easy to be sure what a particular program might be
> doing to the database.
> 
> Some opinions are that this makes for easier
> maintenance.  In the case of
> RPG, I've seen approaches of this type where the
> record layout is pulled
> into the main program via an external data
> structure.  The procedure then
> reads the record from the database, loads it into
> the data structure, and
> then returns the data structure to the main program.
>  This doesn't appear
> better than just having the file defined in the main
> program, as any 
> change
> to the underlying table will surely require a
> recompile of both the main
> program and the procedure in the event that fields
> are added to the table
> or changed.
> 
> I'm trying to think of other systems where using a
> function to do the I/O
> and passing back a data structure is done.  I can't
> think of any.  For
> example, when I write Perl code to access a MySQL
> database, I generally do
> it as simply as possible:
> 
> my $dbh = connect();
> 
> # Get last name, first name from the table
> my $sth = $dbh->prepare( "SELECT ulnam, ufnam FROM
> person") ;
> 
> $sth->execute;
> 
> while ($row = $sth->fetchrow_hashref) {
>      # do stuff with each row
> }
> 
> I don't try to write a function that returns a data
> structure for each
> record, although I suppose I could.  The reason I
> write it this way is
> because it's clear and concise.  I could build this
> as a routine that
> forces the user to implement a call-back to get back
> each row.  I could
> somehow use a static variable or parameter to
> indicate whether the query
> should be run, and then return each row on
> successive calls to the
> function.  I don't see how that's easier or better.
> 
> I don't try to write an object that returns a data
> structure for each
> record, although I suppose I could. I could have an
> object with a method
> for setting the desired database key.  I could have
> another method for
> executing the query.  And another for returning each
> row.  But why?  It's
> building a new interface that's not necessary. 
> There is already a direct
> interface to the database.  Why recreate it?  Anyone
> familiar with the
> database can already retrieve any data in it.  If
> you force someone to
> learn your object-ified way of accessing the data,
> it seems to me you are
> getting in the way of getting the job done.
> 
> If I have this code in 100 different programs, and
> it has to change, I
> think that's probably OK.  The reason is - if you
> have to change the query
> to return a new field, say for example, the person's
> middle initial, I 
> also
> have to change all of the callers to actually *do
> something* with that new
> element.
> 
> I'm not trying to rain on your parade, I am just
> interested in
> understanding what the rationale is.
> 
> Regards,
> Rich
> 
> _______________________________________________
> This is the RPG programming on the AS400 / iSeries
> (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 AS400 / iSeries
> (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
> 
=== message truncated ===


__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
_______________________________________________
This is the RPG programming on the AS400 / iSeries (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.