Why are some users getting "ORA-00942: table or view does not exist"?

Hi all,

I have a view that is working fine for most Oracle users, but a couple of them are getting "ORA-00942: table or view does not exist".  All of these users have a same common Oracle role, which includes the view in question.  A copy of the view is attached.  Any ideas what could be causing this?  I've never seen this type of thing before.


WITH spouse AS
        (SELECT gyvcsps_pidm AS pidm
               ,gyvcsps_spouse_pidm AS sp_pidm
               ,gyvname_id AS ID
               ,gyvname_addr_name AS indiv_mail_name
               ,ayvgrad_us_pref_school AS pref_us_school
               ,ayvgrad_us_pref_year AS pref_us_year
               ,ayvgrad_co_pref_school AS pref_co_school
               ,ayvgrad_co_pref_year AS pref_co_year
           FROM gyvcsps JOIN gyvname ON gyvname_pidm = gyvcsps_spouse_pidm
                LEFT JOIN ayvgrad ON ayvgrad_pidm = gyvcsps_spouse_pidm
-- Person information --
          spriden_pidm AS gyvlabl_pidm
         ,gyvname_id AS gyvlabl_id
         ,    SUBSTR (gyvname_pidm, 2, 3)
           || SUBSTR (UPPER (gyvname_last_name), 1, 3)
           || SUBSTR (gyvname_pidm, 5, 3) AS gyvlabl_mail_id
         ,gyvname_addr_name AS gyvlabl_indiv_mail_name
         ,NVL (gyvname_couple_mail_name, gyvname_addr_name) AS gyvlabl_couple_mail_name
         ,gyvname_last_name AS gyvlabl_last_name
         ,gyvhadr_atyp AS gyvlabl_homeaddr_atyp_code
         ,gyvhadr_add1 AS gyvlabl_homeaddr_line_1
         ,gyvhadr_add2 AS gyvlabl_homeaddr_line_2
         ,gyvhadr_add3 AS gyvlabl_homeaddr_line_3
         ,gyvhadr_city AS gyvlabl_homeaddr_city
         ,gyvhadr_stat AS gyvlabl_homeaddr_st_prov
         ,gyvhadr_zip AS gyvlabl_homeaddr_zip
         ,gyvhadr_natn AS gyvlabl_homeaddr_nation
         ,gyvhadr_delpt AS gyvlabl_homeaddr_delpt
         ,gyvhadr_corr_dig AS gyvlabl_homeaddr_corr_dig
         ,gyvhadr_carr_rt AS gyvlabl_homeaddr_carr_rt
         ,gyvpadr_atyp AS gyvlabl_prinaddr_atyp_code
         ,gyvpadr_add1 AS gyvlabl_prinaddr_line_1
         ,gyvpadr_add2 AS gyvlabl_prinaddr_line_2
         ,gyvpadr_add3 AS gyvlabl_prinaddr_line_3
         ,gyvpadr_city AS gyvlabl_prinaddr_city
         ,gyvpadr_stat AS gyvlabl_prinaddr_st_prov
         ,gyvpadr_zip AS gyvlabl_prinaddr_zip
         ,gyvpadr_natn AS gyvlabl_prinaddr_nation
         ,gyvpadr_delpt AS gyvlabl_prinaddr_delpt
         ,gyvpadr_corr_dig AS gyvlabl_prinaddr_corr_dig
         ,gyvpadr_carr_rt AS gyvlabl_prinaddr_carr_rt
         ,ayvgrad_us_pref_school AS gyvlabl_pref_us_school
         ,ayvgrad_us_pref_year AS gyvlabl_pref_us_year
         ,ayvgrad_co_pref_school AS gyvlabl_pref_co_school
         ,ayvgrad_co_pref_year AS gyvlabl_pref_co_year
         ,gyvemal_email AS gyvlabl_email_addr
-- Spouse information --
   ,      spouse.sp_pidm AS gyvlabl_sp_pidm
         ,spouse.ID AS gyvlabl_sp_id
         ,spouse.indiv_mail_name AS gyvlabl_sp_indiv_mail_name
         ,spouse.pref_us_school AS gyvlabl_sp_pref_us_school
         ,spouse.pref_us_year AS gyvlabl_sp_pref_us_year
         ,spouse.pref_co_school AS gyvlabl_sp_pref_co_school
         ,spouse.pref_co_year AS gyvlabl_sp_pref_co_year
     FROM SPRIDEN LEFT JOIN gyvname ON gyvname_pidm = spriden_pidm
          LEFT JOIN gyvhadr ON gyvhadr_pidm = spriden_pidm
          LEFT JOIN gyvpadr ON gyvpadr_pidm = spriden_pidm
          LEFT JOIN ayvgrad ON ayvgrad_pidm = spriden_pidm
          LEFT JOIN gyvemal ON gyvemal_pidm = spriden_pidm
          LEFT JOIN spouse ON spouse.pidm = spriden_pidm
    WHERE spriden_change_ind IS NULL

Open in new window

Glenn FordSr Applications ProgrammerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

How are the users accessing the view?
Are they using application code?  Is this code pl/sql or is it sql?
How are the users logging into the database?  Does each use have their own Oracle account (I would assume this is the case)?
Does a different Oracle account (to the users) own the view?  Are synonyms used (public or private)?
Glenn FordSr Applications ProgrammerAuthor Commented:
Most users are accessing the view via ODBC-connection in MS Access.  However, I logged one of our problem users into Oracle via Toad, and the same error message comes up.
No additional application code is being used... if I understand your question.
In Toad, I just used a straight "select * from gyvlabl" to test the problem, and the error pops right up.
Each user has his/her own account.  Yes, a different Oracle account owns the view, and a public synonym exists for the view.
Hope this helps.
The test in Toad was a good move, and thanks you have supplied all the info I was looking for.

You say that a role has been used to grant access to the view to all users.  Has a role also been used to grant access to the tables used by the view?

In Toad can you compare the privileges of a user for which the select * from gyvlabl query works and one for which it doesn't work.  In particular note if any table privileges been granted directly to the working user and/or if the "with grant option" has been used.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Big Business Goals? Which KPIs Will Help You

The most successful MSPs rely on metrics – known as key performance indicators (KPIs) – for making informed decisions that help their businesses thrive, rather than just survive. This eBook provides an overview of the most important KPIs used by top MSPs.

Glenn FordSr Applications ProgrammerAuthor Commented:
OK!!!!!!!!!  Thanks for that response!  It got me on the right track, I think.  The role has not assigned access to all of the tables that are used by the view.  Normally this should not be a problem... isn't that right?  (Assigning security to a view normally gives automatic access to the sub-views/tables?)

Well, anyway, does that apply to the WITH statement?  One of the tables in the WITH clause did not have security granted to the role.  So, I assigned that table to the specific user id, just for testing.  And, success!  The view now runs fine for the user that was having the problem.

Is my above analysis correct?
Glenn FordSr Applications ProgrammerAuthor Commented:
Thanks very much for this response!  It led me to the correct answer.  As I was waiting for your follow-up to my last posting, I've indicated "Partially" to the 3 solution questions.  Nonetheless, the response gets an A!

Glenn FordSr Applications ProgrammerAuthor Commented:
I'll follow up for those who may read this thread in the future.
After closing this question, I discovered that the security issue with the WITH clause in a view, is probably an Oracle 9i bug.  We are soon to migrate to 10g, and my testing in 10g shows that you do NOT have to assign security specifically to tables/views in a WITH clause query in 10g, when used within a view.  You need only assign security for the view itself.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Oracle Database

From novice to tech pro — start learning today.