Yosi,
The user that logs in, is granted create session, and granted a role will use synonyms
to access the tables they need. The users in this situation run an application that
will use all of the tables in the instance. (70 GIG data approx 350 tables). The users
do not need to or have the ability to create tables in the instances at our site.
ROR mª¿ªm
>>> [EMAIL PROTECTED] 04/12/01 01:46PM >>>
Ron,
When they log in directly, do they access the tables by fully
qualifying the owner, or do they use synonyms?
Yosi
> -----Original Message-----
> From: Ron Rogers [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, April 12, 2001 12:23 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: Basic logon architecture for multiple apps in a db
>
>
> Yosi
> The users at our location do both methods of logons. Some
> access the database directly with "create session" privileges
> and have a role granted to them that can access the data.
> Other applications have the user login from the application
> access the database and the table privileges are granted to
> the application id. The user assessing the database was
> inplace before I started working here. I control the tables
> the users have assess to by using roles on all of the new
> applications if the developer does not code it to have an
> application id hitting the database. Both methods work well
> and I am still able to "see" the originating user's machine
> name that they logged onto the client with. That helps in
> tracking down who is accessing the servers.
> ROR mª¿ªm
>
> >>> [EMAIL PROTECTED] 04/11/01 04:40PM >>>
> 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: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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: Ron Rogers
> INET: [EMAIL PROTECTED]
>
> 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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: Ron Rogers
INET: [EMAIL PROTECTED]
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: [EMAIL PROTECTED] (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).
