|
Joe, Your first example, getting the GL number account number from the item class. SELECT iim.IPROD, iim.IDESC, iim.ICLAS, iic.ICGL FROM iim join iic on iim.iclas=iic.iclas And if this is something users are doing all over the place in query's and whatnot then a view that does this should be created so they don't have to figure out this join themselves all the time. Now, whether or not it physically chains out to IIC on each row then, or if it reads it from cache, sounds more like a debate for your new website. Your second example on checking the item number. Technically you could write the order record out and check the status of the write. It it was a constraint error you could check the constraint message and then find out that the error was due to the item number being invalid. This may sound clunky to you, but in general people should be putting this kind of error trapping in their code anyway. Because, sooner or later, someone will add constraints and/or triggers to your file and should handle the error(s) reported back. A rare instance might be you chain out and it's a valid item number. User keys in the rest. You write out the order detail record but, in the meanwhile, someone deleted the item number. The problem with most current error trapping is too much of it is assumption. 'If my write fails it must be due to a duplicate key', that kind of garbage. Rob Berendt -- Group Dekko Services, LLC Dept 01.073 PO Box 2000 Dock 108 6928N 400E Kendallville, IN 46755 http://www.dekko.com |-----------------------------+-------------------------------------------| | "Joe Pluta" | | | <joepluta@xxxxxxxxxxxxxxxx| | | m> | To| | Sent by: | "'Midra| | midrange-l-bounces@midrang| nge | | e.com | Systems| | | Technic| | 07/26/2004 09:45 AM | al | | | Discuss| | Please respond to | ion'" | | Midrange Systems | <midran| | Technical Discussion | ge-l@mi| | <midrange-l@xxxxxxxxxxx| drange.| | m> | com> | | | cc| | | | | | Subject| | | RE: | | | Single | | | record | | | access | | | really | | | require| | | d (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. 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. > 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. 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 -- This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/midrange-l or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
