RE: Single record access really required (was RE: Views and Index es)

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
> Sent: Monday, July 26, 2004 10:46 AM
> To: 'Midrange Systems Technical Discussion'
> Subject: RE: Single record access really required (was RE: 
> Views and Indexes)
> 
> 
> > From: CWilt@xxxxxxxxxxxx
> > 
> > Option B is where the solution lies.
> > 
> > How about providing some examples of standard business operations
> where
> > you
> > feel single record access is required and we'll see if there isn't a
> way
> > to
> > remove the requirement.
> 
> You're kidding me, right? Uh, off the top of my head - getting the GL
> account number from the item class.   Requires chaining to the item
> class file with the item class from the item master.

Nope not kidding.  Let see, you have to do this for every item you process.
So instead of doing it one item at a time, you'd fetch the info for every
item at the same time using a join.

Ok, next example.


> 
> And in any business application, there are hundreds and hundreds of
> instances like this.  In fact, that's the idea behind a 
> configurable ERP
> system: you read the database to determine your logic.
> 
> 
> > Most often used one in RPG I can think of is checking a record's
> existence
> > to ensure data integrity.
> > The need for this is eliminated with a properly defined DB that uses
> > constraints properly.
> 
> This is hardly ever used.  We chain to see if the customer entered a
> valid item number, and that's not going to be handled by referential
> integrity.
> 

Sure it could, take whatever the customer gives you write it to the
database.

If it's not valid referential integrity will let you know.

Rob has some good points.  Another he didn't mention was processing it this
way, you're assuming the data is good and only dealing with the exceptions
instead of doing extra work that ends up not being needed when the item was
good.


> 
> > Another place would be a "work-with" type application where 
> a user is
> > presented with a set of items from which they chose one to edit or
> > display.
> > Off the top of my head, one could possibly use the same cursor that
> > presents
> > the set to present the single item.  This would eliminate the
> performance
> > differences that you've seen in your testing.  Perhaps somebody else
> has a
> > better idea.
> 
> How could you use the same cursor?  By doing somehow 
> calculating the row
> number and doing a FETCH -N?  It's been stated (though not proven
> quantitatively) that relative fetches include I/O overhead of 
> their own.

Actually you've already got the row number.  Just by knowing which subfile
record it was.

I/O overhead for relative fetches is not something I've heard before.
Certainly something to consider.  Where was this discussed, here on this
list?


> 
> And that's not really the point.  The point is that you have no real
> answer to this, you're just winging it.  And that's really not
> acceptable in a technical discussion.
> 
> At least not to me.  I will no longer dispute "maybes" and 
> "mights".  If
> you have a solution, then write it, test it, and let us know the
> results.  As of today, the day of "possible" solutions used 
> as arguments
> is over, at least for me.  From now on, the only valid solution is one
> that has been tested.  And those will be posted at the IAAI website.
> 
> Joe
> 

To bad Joe.  I think that brainstorming here of "possible" solutions is a
good thing.  I for one am still trying to understand where/how to use SQL in
place of RPG.  It's not that I already have an ERP application with no RPG
I/O.  Nor do I necessarily think that this is the best way to do it.  I
simply can read the writing on the wall, I know I need to understand how to
use SQL I/O.  If nothing else, it gives us any idea of what to test and post
on IAAI..

Charles