home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / database / ingres / 1029 < prev    next >
Encoding:
Text File  |  1992-07-29  |  3.2 KB  |  76 lines
  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!wupost!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!mail-to-news-gateway
  3. From: CS_PAUL@GSBVAX.UCHICAGO.EDU (Paul Ford 312/702-0335)
  4. Subject: Re: select * with a 3-way join having same column names in ESQL/C
  5. Message-ID: <920729102620.29401bab@GSBVAX.UCHICAGO.EDU>
  6. Sender: daemon@nrao.edu
  7. Organization: National Radio Astronomy Observatory
  8. Date: Wed, 29 Jul 1992 15:26:20 GMT
  9. Lines: 65
  10.  
  11. Alan Crosswell writes:
  12.  
  13. >I had a code segment which said:
  14. >
  15. >       exec sql declare x cursor for
  16. >          select *
  17. >            from hosts h, hwaddr hw, ip i
  18. >              where h.hname=i.hname
  19. >               and i.ipaddr=hw.ipaddr;
  20. >
  21. >       exec sql fetch x into :hosts,:ip,:hwaddr;
  22. >
  23. > I got random wierd results under 6.3 and 6.4 include garbage data and
  24. > numeric type conversion error messages until I changed the code to select
  25. > explicit columns and fetch into explicit struct members in the same order.
  26.  
  27. Your select results are in a different order than your fetch results.  You
  28. might try fetching into the structures in the same order that you named the
  29. tables in the from clause:
  30.  
  31.     exec sql fetch x into :hosts, :hwaddr, :ip ;
  32.  
  33. Or, you could force the result columns into the fetch order order by doing
  34.  
  35.     select h.*, i.*, hw.*
  36.  
  37. But, I think your choice to name the result and fetch columns explicitly was
  38. the right one.  You might consider some of the disadvantages of the * notation
  39. for anything but interactive SQL (in addition to the one you just ran into):
  40.  
  41. * notation causes code to break when columns are added or reordered:
  42.  
  43.     When (not if) you change the structure of a table, by adding columns or
  44.     reordering columns, your embedded code will break until you rerun
  45.     DCLGEN, recompile and relink.  On the other hand, if you've explicitly
  46.     named every  column in the select statement, your embedded program will
  47.     continue to run without error.  (What your program should do with the
  48.     additional column is a separate issue.)  Column deletions are still a
  49.     problem, but they tend to be much rarer than additions.
  50.  
  51. * notation makes code harder to read and maintain
  52.  
  53.     Naming all the result columns is a form of documentation.  If your code
  54.     has to be maintained in the future by someone less familiar with the
  55.     tables (after a short interval that might be you :-) it is a lot easier
  56.     to figure out what's coming from where with an explicit list of column
  57.     names.
  58.  
  59. Hard experience over many years has taught us _NEVER_ to use * notation in
  60. our 4GL or embedded 3GL select statments.  The extra editing effort up
  61. front (a lot of cut and paste of lists of columns, usually started by
  62. sucking the DCLGEN file into the editor for the complete current list) pays
  63. for itself many times over in robustness and ease of maintenance.  Don't
  64. forget that the time spent actually writing code ends up being only a small
  65. fraction of the total cost of developing and maintaining software.
  66.  
  67. Paul Ford
  68. -----------------------------------------------------------------------
  69. GSB Computing Services                  312.702.0335
  70. University of Chicago                   cs_paul@gsbvax.uchicago.edu
  71. 1101 E. 58th Street
  72. Chicago IL 60637
  73. -----------------------------------------------------------------------
  74.  
  75.  
  76.