|
Gord, I'm going to look for more stuff to read about this. I use cursors now. I have pgms which return the entire record because I use most if not all of the data in the record. I have pgms which return the entire record so I can use the same program in many programs, where I don't know yet what data is wanted. Thanks, Phil > -----Original Message----- > From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On > Behalf Of Gord Royle > Sent: Friday, September 14, 2001 2:55 PM > To: 'rpg400-l@midrange.com' > Subject: RE: SQL Problem > > > Using "select *" is bad form in any tool and will certainly cause a lot of > grief when you start using cursors. You should never bring back any more > information than is required. If you force the beast to return > all (say 500) > fields of a record when you only want two, what will be the impact on > performance(throughput/memory/etc). I know that we all have AS400's with > massive amounts of resources available, but why use them needlessly. > > Gord Royle > > -----Original Message----- > From: lisa.thomas@Hayssen.com [mailto:lisa.thomas@Hayssen.com] > Sent: Friday, September 14, 2001 2:39 PM > To: rpg400-l@midrange.com > Subject: RE: SQL Problem > > > I think the key is not necessarily how often your database is changing now > but perhaps how much flexibility you have in rearranging and changing your > database in the future. The idea behind explicitly listing the fields in > SQL is that if they move the SQL doesn't and shouldn't care. If you add > fields in the middle of the structure SQL doesn't and shouldn't care. > > -----Original Message----- > From: Phil [mailto:sublime78ska@yahoo.com] > Sent: Friday, September 14, 2001 2:34 PM > To: rpg400-l@midrange.com > Subject: RE: SQL Problem > > > Then also: > > select custid from cusmst into :@custid > > where custid and @custid are 5A at compile time then custid is changed to > 5,0. > > If the pgm is not recompiled then there will be a run time error. > > Correct? If so I still don't understand why using * is bad form. > It seems > to me that using embedded sql at all is inherently less safe than using > native I/O. > > Personally I have not been in a situation where the database was changed > (other than app's still under development) except for Y2K. That > may be why > I'm having a hard time seeing this. > > Phil > > > -----Original Message----- > > From: rpg400-l-admin@midrange.com [mailto:rpg400-l-admin@midrange.com]On > > Behalf Of MWalter@hanoverwire.com > > Sent: Friday, September 14, 2001 1:46 PM > > To: rpg400-l@midrange.com > > Subject: RE: SQL Problem > > > > > > > > Regardless of how you change the table, DDS or SQL, if you change the > > structure of the table, and the corresponding host DS is not > changed. You > > run the risk of contaminating a field in the data structure. > > Maybe adding a > > field to a table was a bad example. Changing the field length of a field > > might be a better one. Here is a scenario. > > > > You have a table, say: CharField1 10, CharField2, 10, ZoneField1 5,0 > > ZoneField2 5,0. > > You write a program specifying your table as the EXTNAME in your hostds. > > > > Now you change the length of CharField2 to 15. You don't compile the > > program. Your host ds still says that CharField2 is 10. When > the record is > > fetched into HostDS, wouldn't ZoneField1 contain character data? > > > > Maybe I'm wrong about this. I haven't tried to prove it. If I am, by all > > means let me know. > > > > > > Thanks, > > > > Mark > > > > > > Mark Walter > > Sr. Programmer/Analyst > > Hanover Wire Cloth a div of CCX, Inc. > > mwalter@hanoverwire.com > > http://www.hanoverwire.com > > 717.637.3795 Ext.3040 > > > > <SNIP> > > > > You can use ALTER TABLE in SQL to add a field. I THINK, if you add a > > field > > using ALTER TABLE and leave it null capable, your existing > programs should > > continue to run without any problems. > > > > > > _______________________________________________ > > This is the RPG programming on the AS400 / iSeries (RPG400-L) > mailing list > > To post a message email: RPG400-L@midrange.com > > To subscribe, unsubscribe, or change list options, > > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > > or email: RPG400-L-request@midrange.com > > Before posting, please take a moment to review the archives > > at http://archive.midrange.com/rpg400-l. > > > > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > 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@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > > Cott - The Leader in Premium Retailer Brand Beverage Innovation. > > > _______________________________________________ > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@midrange.com > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/cgi-bin/listinfo/rpg400-l > or email: RPG400-L-request@midrange.com > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com
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.