home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #3 / NN_1993_3.iso / spool / comp / database / sybase / 707 < prev    next >
Encoding:
Internet Message Format  |  1993-01-21  |  3.8 KB

  1. Path: sparky!uunet!olivea!pagesat!spssig.spss.com!brent
  2. From: brent@spss.com (Brent Lambert)
  3. Newsgroups: comp.databases.sybase
  4. Subject: Re: Accessible Databases & Objects
  5. Message-ID: <C17soM.CLM@spss.com>
  6. Date: 21 Jan 93 17:31:33 GMT
  7. References: <C0KAuu.KFD@well.sf.ca.us> <27896@sybase.sybase.com>
  8. Sender: news@spss.com (Net News Admin)
  9. Organization: SPSS, Inc. - portable code group
  10. Lines: 68
  11.  
  12. In article <27896@sybase.sybase.com>, ben@oy.sybase.com (Benjamin E. Von Ullrich) writes:
  13. > In article <C0KAuu.KFD@well.sf.ca.us>, mharper@well.sf.ca.us (Michael J. Harper) writes:
  14. > |> I would like to issue a SELECT statment that will tell me what databases I
  15. > |> can USE.  Getting the complete list of databases is a cinch; how do I list
  16. > |> only those to which I have access?
  17. > you must have access to a database (your suid or 'guest' must be listed
  18. > in the sysusers or sysalternates tables) to see if you have access.
  19. > (yes, that's a .. recursive sentence, but it is TRUE!).  the only way
  20. > to know if you are a user is to be one in the first place, as you won't
  21. > be able to open a database without being a user of it.
  22. > the only way around this is to have guest access added to all database, or
  23. > have the sa create a system stored procedure (a procedure beginning
  24. > with "sp_" residing in the master database) that takes a username as a
  25. > parameter, and is coded to search all databases for that user.
  26.  
  27. As a side note, Ben's suggestions are fine for interactive use or internal
  28. applications, but if you're working on an application for external use, eg.
  29. commercial software, the only way you can rely on these workarounds is to 
  30. make them part of your application's installation procedure.  If your app.
  31. is closely integrated with the database anyway, this is fine, but if your
  32. app. is only incidently related to the database, then it's a real pain.
  33.  
  34. Hey Sybase:  How about providing a system stored procedure (or better yet,
  35.              a simple view in the master database) to do this?
  36.  
  37.  
  38. > |> Once I know which databases I can access, how can I list the tables and
  39. > |> views which I can access within a database?
  40. > declare @login sysname (30)
  41. > select @login=user_name()
  42. > exec sp_helprotect @login
  43. > exec sp_helprotect 'public'
  44. > this prints out access for all objects.  if you want to get only tables and
  45. > views, get the last two queries out of the text for sp_helprotect and adapt
  46. > them to look for only these object types.
  47.  
  48. Again, this is fine for interactive use, but sifting through the output in an
  49. Open-Client application can be a pain.  For this, I wrote a couple of BIG 
  50. queries which join sysobjects, syscolumns, and sysprotects and select into a
  51. temporary table, then got the results from the temporary table.  A 'union'
  52. would have helped, but the version of Sybase I had to support lacked UNION.
  53.  
  54. In retrospect, sifting the output of sp_helprotect might have been easier.
  55. But if I had known how to "... get the last two queries out of the text for
  56. sp_helprotect ...", writing my own queries would have been easier, too.  Sounds
  57. like if I had talked to Ben when I called Tech Support many months ago, my whole
  58. task would have been easier.
  59.  
  60. Hey Sybase:  How about providing a system stored procedure (or better yet,
  61.              a simple view in each database) to do this?  (Oracle does :->)
  62.  
  63. If you want some more info on how I solved the problem, Email me (brent@spss.com)
  64. and we can discuss it off-line.
  65.  
  66.  
  67. > ------
  68. > Benjamin von Ullrich         all words are those of the author, not Sybase.
  69. > ben@sybase.com                   {pyramid,pacbell,sun,lll-tis}!sybase!ben
  70.  
  71. -- 
  72. The above statements are not the opinions or policies of SPSS Inc.
  73. The above statements may not be the opinions of Brent Lambert.
  74. The first disclaimer is a policy of SPSS Inc.
  75. Subsequent disclaimers are probably the opinion of Brent Lambert.
  76.