Re:RE: Re[2]: Basic logon architecture for multiple apps in

Yosi,

    Your second case is how I prefer things done. As to how the application handles resolving objects, that I leave up to the programmer. Both methods work although if you expect the end user to do his own adhoc queries it's better to have a synonym.

Dick Goulet

____________________Reply Separator____________________
Author: Yosi_at_comhill.com
Date:       4/12/2001 9:15 AM

Dick,

Thanks. So a user can have two different logons? Say, YOSI_OE for when I log on to the Order Entry Application and YOSI_STAT for when I use the Statistics app? Is this what you mean?

Or, as I've been doing, just user YOSI, who's assigned both the OE_USER and the STATS_USER roles, but then how do you qualify objects - In code or as synonyms? And what happens to conflicts?

Thanks again, and thanks to all who've been responding.

Yosi

> -----Original Message-----
> From: dgoulet_at_vicr.com [mailto:dgoulet_at_vicr.com]
> Sent: Thursday, April 12, 2001 10:22 AM
> To: Multiple recipients of list ORACLE-L
> Subject: Re[2]: Basic logon architecture for multiple apps in a db
>
>
> I prefer having multiple logons. There should be a generic,
> self explanatory
> schema that owns the objects followed by one of more roles
> that grants are made
> to followed by individual user accounts. That way it's easy
> to find out who's
> plugging up the drain every once in a while. Also if you
> need any kind of audit
> trail on the records it's easy to get one.
>
> Now for third party apps your stuck.
>
> Dick Goulet
>
> ____________________Reply Separator____________________
> Author: Regina Harter <rharter_at_emc-inc.com>
> Date: 4/11/2001 2:06 PM
>
> We have the users log in as themselves, because that was the
> only way to
> handle the permissions properly. We also use fully qualified
> table names
> rather than synonyms, though that was mostly because we have
> data split
> among several schemas using identical table names. We just
> make the table
> owner dynamic and swap in the proper name at runtime. Works
> much better
> than trying to handle swapping and redefining synonyms.
>
> At 12:40 PM 4/11/01 -0800, you wrote:
> >O Esteemed and Wise Colleagues,
> >
> >(My first sending of this didn't seem to make it to the
> list... Knowing
> >our mail server it may show up in a few weeks!)
> >
> >How do application (Forms or other) users access your tables?
> >Do they logon as themselves? Do you switch their logon behind
> >their backs to that of the app owner (like Oracle Apps does?)
> >
> >I'm wrestling with this now.
> >
> >The way I see it, I've got two choices, with several subchoices:
> >
> >1. User logs in as self and accesses the tables either:
> >
> > a. via synonyms (to tables or to table API package), or
> > b. via full table path qualification, i.e., GL.ACCOUNT or
> > GL.ACCOUNT_API (package).
> >
> >2. User logs in (knowingly or unknowingly via behind the scenes
> > smoke-and-mirrors) as app owner, and accesses tables directly.
> >
> >Peronally, I much prefer the logging in as self route. It's
> >easier to trace users, sessions, security, access, performance,
> >etc. I also prefer using synonyms, since most application
> >design environments - including Forms - don't fully qualify
> >tables or views by default.
> >
> >The problem is that synonym names can conflict between applications.
> >One solution is to prefix the app_short_name to the name of each
> >table or view. I hate that. Another thought is to create synonyms
> >dynamically as the user logs on to an application. That's no good
> >if the user logs on to two apps at the same time.
> >
> >If you go with relogging in as the app owner, you somehow have
> >to keep track of who the user really is (some common package
> >variable, most likely) and then use that info as needed. That
> >sounds like lots of extra code.
> >
> >So, how do YOUR users access your apps? Any ideas? I need guidance,
> >and I'll really, truly, honestly, very much appreciate any you can
> >send my way.
> >
> >TIA,
> >
> >Yosi
> >
> >
> >--
> >Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >--
> >Author: Yosi Greenfield
> > INET: yosi_at_comhill.com
> >
> >Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> >San Diego, California -- Public Internet access /
> Mailing Lists
> >--------------------------------------------------------------------
> >To REMOVE yourself from this mailing list, send an E-Mail message
> >to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> >the message BODY, include a line containing: UNSUB ORACLE-L
> >(or the name of mailing list you want to be removed from). You may
> >also send the HELP command for other information (like subscribing).
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Regina Harter
> INET: rharter_at_emc-inc.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author:
> INET: dgoulet_at_vicr.com
>
> Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> San Diego, California -- Public Internet access / Mailing Lists
> --------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
> the message BODY, include a line containing: UNSUB ORACLE-L
> (or the name of mailing list you want to be removed from). You may
> also send the HELP command for other information (like subscribing).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: Yosi_at_comhill.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: dgoulet_at_vicr.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).