home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / comp / database / ingres / 2222 < prev    next >
Encoding:
Text File  |  1993-01-11  |  3.5 KB  |  77 lines

  1. Newsgroups: comp.databases.ingres
  2. Path: sparky!uunet!cs.utexas.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!uchinews!gsbacd.uchicago.edu!cs_mj
  3. From: cs_mj@gsbacd.uchicago.edu (Mark Jaeger)
  4. Subject: Re: DB admin tools
  5. Message-ID: <1993Jan11.135316.1@gsbacd.uchicago.edu>
  6. Lines: 65
  7. Sender: news@uchinews.uchicago.edu (News System)
  8. Organization:     
  9. References: <ROBM.92Dec22120335@ishtar.Berkeley.EDU> <1993Jan5.004315.1@gsbacd.uchicago.edu> <1993Jan5.190338.23433@pony.Ingres.COM>
  10. Date: Mon, 11 Jan 1993 19:53:16 GMT
  11.  
  12. In article <1993Jan5.190338.23433@pony.Ingres.COM>, billc@Ingres.COM 
  13. (Bill Coffin) writes:
  14.  
  15. > iidbdepends isn't really a System Catalog, and so it is not supported
  16. > on all gateways or in STAR.  Also, we don't guarantee that it won't
  17. > change, the way we guarantee catalogs like iitables.  So you can use
  18. > iidbdepends, but without connectivity and without guaranteed backward
  19. > compatibility.
  20.  
  21. Maybe we're just quibbling about apples and oranges, but I thought that
  22. "system catalog" meant anything that is in an empty, newly-created
  23. database.  At least, that's what it meant in version 5.  I think it
  24. might be more correct to say that "iidbdepends" is not part of the
  25. Standard Catalog Interface, but rather it is an internal dbms system
  26. catalog, for INGRES internal use only.  
  27.  
  28. The tables in the Standard Catalog Interface are mostly views on the
  29. internal system catalogs.  Bill is correct in his warning that one
  30. should not write tools that _depend_ on the internal catalogs--use the
  31. SCI instead.  However, we, as users, still need to get to them
  32. sometimes.  This happened to me recently when I had to delete rows from
  33. iirelation, iiattribute, and iiindex due to a bug in the JSP server.
  34.  
  35. > My reccomendation to Rob McNicholas, the original poster, would be to
  36. > use views liberally while developing the applications.  You can use
  37. > many tricks to avoid the necessity of redefining tables.
  38.  
  39. Bill's suggestion doesn't speak to most of the reasons that I need to
  40. drop and recreate a table: adding a column; making a column longer; and
  41. renaming a column.  That we do this so frequently is probably due to a
  42. flawed development process, with an inadequate analysis and design
  43. phase, but the fact remains that we users _do_ have to change our tables
  44. from time to time.  The copydb tool has long been inadequate to the
  45. task, really since version 6, when INGRES first started dropping views
  46. when you drop a table.
  47.  
  48. I have attached a query that I wrote to find the dependencies on a given
  49. table, although I won't vouch for its accuracy.  It only goes one level
  50. deep, also, so it won't catch a view that is defined on a view.  But
  51. it's a start.
  52.  
  53. --Mark Jaeger                internet: cs_mj@gsbvax.uchicago.edu
  54. Graduate School of Business        yellnet:  (312) 702-0328
  55. University of Chicago            faxnet:   (312) 702-0233
  56. Disclaimer: My opinions are my own and not those of my employer.
  57. Je suis un virus.  Prends ton pied et copie moi a ta .signature.
  58.  
  59. ================================================================================
  60. select distinct obj_type = 'View'
  61.     , obj_owner = rv.relowner , obj_name = rv.relid
  62.     , base_name = rt.relid
  63.     from iirelation rv , iidbdepends d , iirelation rt
  64.     where 1=1
  65.     and rt.relowner = '$t_owner' and rt.relid = '$t_name'
  66.     and rv.reltid = d.deid1 and rv.reltidx = d.deid2
  67.     and rt.reltid = d.inid1 and rt.reltidx = d.inid2
  68.     and d.itype = 0 and d.dtype = 17 and qid = 0
  69. union all select distinct obj_type = 'Rule'
  70.     , obj_owner = r.rule_owner , obj_name = r.rule_name
  71.     , base_name = r.table_name
  72.     from iirules r
  73.     where 1=1
  74.     and r.rule_owner = '$t_owner'
  75.     and r.table_name = '$t_name'
  76.  
  77.