Results 1 to 11 of 11
  1. #1
    Join Date
    Jun 2011
    Posts
    7

    Unanswered: OraOLEDB From VBScript As Standard User

    I'm having a strange issue trying to pull information from an Oracle database through a VBScript using the provider OraOLEDB. When I run the script as a user in the Administrator group it runs fine, but if I run it as a standard user, not in the admin group, it returns an unspecified error when it attempts to connect to the database. I have double checked that all users have read and execute permissions to everything under the ORACLE_HOME directory. Does anyone know of anywhere else I can start looking?

    Thanks,
    =-Jameson

  2. #2
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    >Does anyone know of anywhere else I can start looking?
    Look in the clue locker.

    You report that you do something (which we don't know) & get some error (which we don't know), then you ask us to assist.
    The total lack of meaningful details, precludes any assistance.
    Is COPY & PASTE broken for you?
    Last edited by anacedent; 06-29-11 at 16:40.
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  3. #3
    Join Date
    Jun 2011
    Posts
    7
    Quote Originally Posted by anacedent View Post
    Is COPY & PASTE broken for you?
    Actually, it isn't possible to copy from the error message dialog I'm getting, and the error is basically useless, but here it is for your amusement:

    Error: Unspecified error
    Code: 80004005
    Source: OraOLEDB

    Like I said, the script works fine when run as an Administrator, so it's not likely that it contains anything of use. If anyone would like to request specific information that may help in diagnosing the issue, or actually has something useful to say, I look forward to hearing from you.

  4. #4
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  5. #5
    Join Date
    Jun 2011
    Posts
    7
    Code:
    Dim ODBC, Query
    Set ODBC = CreateObject("ADODB.Connection")
    ODBC.ConnectionString = "Provider=OraOLEDB.Oracle; Data Source=blahblahblah.world; User ID=none-o; Password=yo-business;"
    ODBC.Open
    That's the portion of the script that generates the error with names changed to protect the innocent if you don't understand where the error is coming from.

  6. #6
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  7. #7
    Join Date
    Jun 2011
    Posts
    7
    Like I said, all users already have Read & Execute on %ORACLE_HOME% including the BIN directory.

  8. #8
    Join Date
    Jun 2011
    Posts
    7
    My script isn't making it as far as his. He said he was making it to a line cmd.Execute in his script which is after his line objConnection.Open SysCatConnString which is the equivalent to where mine is breaking.

  9. #9
    Join Date
    Aug 2003
    Location
    Where the Surf Meets the Turf @Del Mar, CA
    Posts
    7,776
    Provided Answers: 1
    >Like I said, all users already have Read & Execute on %ORACLE_HOME% including the BIN directory.
    Necessary, but not always sufficient.
    Users must have READ access from TOP directory down to BIN directory; inclusive.
    You can lead some folks to knowledge, but you can not make them think.
    The average person thinks he's above average!
    For most folks, they don't know, what they don't know.
    Good judgement comes from experience. Experience comes from bad judgement.

  10. #10
    Join Date
    Jun 2011
    Posts
    7
    Quote Originally Posted by anacedent View Post
    >Like I said, all users already have Read & Execute on %ORACLE_HOME% including the BIN directory.
    Necessary, but not always sufficient.
    Users must have READ access from TOP directory down to BIN directory; inclusive.
    To be on the safe side, I added Domain Users (all users with be AD authenticated) with Read & Execute, and checked the following:
    Code:
    C:\oracle - Domain Users - Read & Execute, List Folder Contents, Read
    C:\oracle\product - Domain Users - Read & Execute, List Folder Contents, Read
    C:\oracle\product\10.2.0 - Domain Users - Read & Execute, List Folder Contents, Read
    C:\oracle\product\10.2.0\client_1 - Domain Users - Read & Execute, List Folder Contents, Read
    C:\oracle\product\10.2.0\client_1\BIN - Domain Users - Read & Execute, List Folder Contents, Read
    C:\oracle\product\10.2.0\client_1\BIN\cemutls.exe - Domain Users - Read & Execute, Read

  11. #11
    Join Date
    Jun 2011
    Posts
    7

    Gave Up

    Well, I gave up trying to use this connector, and wound up just running SQL Plus, and reading the output. It worked the first time, and every time since. I still have no idea why regular users are able to use SQL Plus to query the database, but not the OraOLE connector.

Posting Permissions

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