|
A logical file _is_ an access path. You're comparing apples to oranges when comparing RPG with a logical vs. SQL with no access path In any event, if you can SETLL and READ a logical file with RPG then SQL should be able to make use of the same access path. If SQL isn't using the logical, then you have a problem. Usually, it's your SQL statement, though as I recall select/omit logicals don't play real well with SQL. One mistake many people make it to specify the logical in the SQL statement, you shouldn't do that as it causes more work for the query engine. Again, for the best performance, both RPG and SQL need existing access paths. SQL's advantage is that the indexes it uses can be more generic and can be combined on the fly. While many logicals are for a single specific purpose. So you can end up with fewer SQL indexes than you would have logicals. Fewer indexes means less time to maintain access paths when the physical file is changed. Sure combining access paths on the fly takes some time vs. having an existing perfect index. But, that time is more than made up by the fact that SQL only makes one trip from the HLL to the lower parts of the OS vs. RPG making the same trip for every record. Given a level playing field, SQL will always beat RPG when dealing with result sets of more than a handful of records. HTH, Charles Wilt -- iSeries Systems Administrator / Developer Mitsubishi Electric Automotive America ph: 513-573-4343 fax: 513-398-1121 > -----Original Message----- > From: rpg400-l-bounces+cwilt=meaa.mea.com@xxxxxxxxxxxx > [mailto:rpg400-l-bounces+cwilt=meaa.mea.com@xxxxxxxxxxxx] On > Behalf Of Michael_Schutte@xxxxxxxxxxxx > Sent: Friday, March 31, 2006 9:21 AM > To: RPG programming on the AS400 / iSeries > Subject: RE: SQL Update in RPGLE. > > ??? RPG doesn't have an access path? If you can SETLL and > READE right > away on a Logical file, you can get faster processing time > when SQL "may" > need to create a new access path. I've had RPG programs run > faster than > SQL and SQL programs that have run faster than RPG. The slower SQL > programs are usually because the SQL couldn't find a suitable > access path > and created a new one on the fly. > > Michael Schutte > Work 614-492-7419 > email michael_schutte@xxxxxxxxxxxx > > > > > "Wilt, Charles" > > <CWilt@xxxxxxxxxx > > om> > To > Sent by: "RPG programming on > the AS400 / > rpg400-l-bounces@ iSeries" > <rpg400-l@xxxxxxxxxxxx> > midrange.com > cc > > > > Subject > 03/31/2006 09:15 RE: SQL Update in > RPGLE. > AM > > > > > > Please respond to > > RPG programming > > on the AS400 / > > iSeries > > <rpg400-l@midrang > > e.com> > > > > > > > > > > > Not really. When you consider that when RPG doesn't have an access > path, it has to read every record. > > SQL _might_ have to do the same thing. But the advantage SQL has over > RPG is that SQL can build a new access path on the fly from multiple > existing access paths. > > HTH, > > Charles Wilt > -- > iSeries Systems Administrator / Developer > Mitsubishi Electric Automotive America > ph: 513-573-4343 > fax: 513-398-1121 > > > > -----Original Message----- > > From: rpg400-l-bounces@xxxxxxxxxxxx > > [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of > > Michael_Schutte@xxxxxxxxxxxx > > Sent: Thursday, March 30, 2006 4:22 PM > > To: RPG programming on the AS400 / iSeries > > Subject: RE: SQL Update in RPGLE. > > > > Except when SQL has to create the ACCESS PATH. If there > > isn't an already > > defined access path, SQL will build one and then the length > > becomes longer. > > > > Michael Schutte > > Work 614-492-7419 > > email michael_schutte@xxxxxxxxxxxx > > > > > > > > > > "Wilt, Charles" > > > > <CWilt@xxxxxxxxxx > > > > om> > > To > > Sent by: "RPG programming on > > the AS400 / > > rpg400-l-bounces@ iSeries" > > <rpg400-l@xxxxxxxxxxxx> > > midrange.com > > cc > > > > > > > > Subject > > 03/30/2006 04:14 RE: SQL Update in > > RPGLE. > > PM > > > > > > > > > > > > Please respond to > > > > RPG programming > > > > on the AS400 / > > > > iSeries > > > > <rpg400-l@midrang > > > > e.com> > > > > > > > > > > > > > > > > > > > > RPGLE is not "definitely much faster" than SQL. > > > > RPGLE is faster when working one record at a time. Once you start > > working with multiple records, then SQL moves ahead. > > > > HTH, > > > > Charles Wilt > > -- > > iSeries Systems Administrator / Developer > > Mitsubishi Electric Automotive America > > ph: 513-573-4343 > > fax: 513-398-1121 > > > > > > > -----Original Message----- > > > From: rpg400-l-bounces@xxxxxxxxxxxx > > > [mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of Mike > Troxclaire > > > Sent: Thursday, March 30, 2006 3:57 PM > > > To: rpg400-l@xxxxxxxxxxxx > > > Subject: RE: SQL Update in RPGLE. > > > > > > All the inputs are correct and I agree that there is no need > > > for SQL if only > > > one file is involved but I already have a ready made > > > complicated SQL query > > > so I wanted to go the SQL way. I agree that F specs were not > > > needed at all. > > > The update query ran just fine when I added "WITH NC" at the > > > end of the SQL > > > statement. > > > > > > It would be very interesting to see some input on > > > performance when it > > > comes to SQL compared to RPGLE. RPGLE would definitely be > > > much faster but > > > just wondering by how much. I have atleast 12 files in my > > > UPDATE statement. > > > > > > Cheers, > > > > > > Mike. > > > > > > _________________________________________________________________ > > > > -- > > 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 > > 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 > 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 > 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 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
