Results 1 to 7 of 7
  1. #1
    Join Date
    May 2007
    Posts
    3

    Unanswered: Disable sqlforms access from users

    I am working as DBA. How can i disable sqlforms30 (Oracle7 Under Unix)access from user

  2. #2
    Join Date
    Jan 2004
    Location
    Croatia, Europe
    Posts
    4,094
    Provided Answers: 4
    Do you not want your users to use forms (so that they couldn't enter / update / delete records), or prevent them using SQL*Forms (so that the couldn't mess up existing forms and write new ones)?

  3. #3
    Join Date
    May 2007
    Posts
    3
    Quote Originally Posted by Littlefoot
    Do you not want your users to use forms (so that they couldn't enter / update / delete records), or prevent them using SQL*Forms (so that the couldn't mess up existing forms and write new ones)?
    Yes i want the same thing

  4. #4
    Join Date
    Jun 2004
    Location
    Liverpool, NY USA
    Posts
    2,509
    No, he is asking what type of restriction do you want.

    1) Not being able to run any form
    or
    2) Not being able to run the form designer so that existing forms can not be created or modified.
    Bill
    You do not need a parachute to skydive. You only need a parachute to skydive twice.

  5. #5
    Join Date
    Jan 2004
    Location
    Croatia, Europe
    Posts
    4,094
    Provided Answers: 4
    OK, whichever it is, let me say a word or two about it. Please note that this comes from OpenVMS Oracle7 (and its developing tools) experience, not UNIX one.

    First, an easy answer: if you'd like to restrict access to data which are behind the form, simply GRANT (or REVOKE existing) privileges to a specific user. If you don't want it to see anything, don't grant him/her anything. Otherwise, if you grant this user with certain privileges, take a look at coding standards your developers have used. If they used 'schema_name.table_name' references to objects, fine. If not, you'll have to create synonyms for all those objects in order to make forms properly run.

    Now a more complicated answer: I wish you have asked about restricting access to SQL*Report Writer or SQL*Menu - those products require additional settings: running SRW_GRNT.SQL as a privileged user for Report Writer, and connecting to SQL*Menu as a privileged user, granting Access to a user and creating role under Security submenu.

    Unfortunately (from your point of view), SQL*Plus and SQL*Forms are accessible always - you don't have to do anything to make your users use those tools. Of course, apart from granting CONNECT and RESOURCE roles (predefined roles which are now obsolete, they still exist but only for backward compatibiliy). Now, if you don't grant those roles, user will not be able to logon as it will not have a CREATE SESSION privilege. What you might do is REVOKE both 'connect' and 'resource' roles and grant privileges one by one and, at the same time, testing which combination will be enough for user to access date, but disable him/her to run SQL*Forms. However, this seems to be a quite painful approach.

    I'd say that you'll have to restrict access to 'sqlforms' executable on operating system level. I'm sorry, but I really wouldn't know how to do it using Oracle.

  6. #6
    Join Date
    May 2007
    Posts
    3
    Quote Originally Posted by Littlefoot
    OK, whichever it is, let me say a word or two about it. Please note that this comes from OpenVMS Oracle7 (and its developing tools) experience, not UNIX one.

    First, an easy answer: if you'd like to restrict access to data which are behind the form, simply GRANT (or REVOKE existing) privileges to a specific user. If you don't want it to see anything, don't grant him/her anything. Otherwise, if you grant this user with certain privileges, take a look at coding standards your developers have used. If they used 'schema_name.table_name' references to objects, fine. If not, you'll have to create synonyms for all those objects in order to make forms properly run.

    Now a more complicated answer: I wish you have asked about restricting access to SQL*Report Writer or SQL*Menu - those products require additional settings: running SRW_GRNT.SQL as a privileged user for Report Writer, and connecting to SQL*Menu as a privileged user, granting Access to a user and creating role under Security submenu.

    Unfortunately (from your point of view), SQL*Plus and SQL*Forms are accessible always - you don't have to do anything to make your users use those tools. Of course, apart from granting CONNECT and RESOURCE roles (predefined roles which are now obsolete, they still exist but only for backward compatibiliy). Now, if you don't grant those roles, user will not be able to logon as it will not have a CREATE SESSION privilege. What you might do is REVOKE both 'connect' and 'resource' roles and grant privileges one by one and, at the same time, testing which combination will be enough for user to access date, but disable him/her to run SQL*Forms. However, this seems to be a quite painful approach.

    I'd say that you'll have to restrict access to 'sqlforms' executable on operating system level. I'm sorry, but I really wouldn't know how to do it using Oracle.

    Ok, Thanks

  7. #7
    Join Date
    Jun 2004
    Location
    Liverpool, NY USA
    Posts
    2,509
    If you don't want them to be able to run any forms, don't install the forms runtime on the workstation. If you don't want them being able to modify a form, don't install oracle forms designer. If it is network installed, setup the approporate priviledges on the network share so that the specific users can't access the directory where it is installed.
    Bill
    You do not need a parachute to skydive. You only need a parachute to skydive twice.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •