RE: SQL Problem

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