Podczas tworzenia widoku generowany jest błąd ORA-00942

Pierwszym krokiem w diagnozowaniu problemu podczas tworzenia widoku jest wypróbowanie select część na własną rękę. W takim przypadku nadal otrzymasz błąd ORA-00942, ale problem jest teraz tylko kwestią zapytania i dostępu, a nie dotyczy konkretnego widoku.

Gdy otrzymasz ORA-00942:tabela lub widok nie istnieje , to dlatego, że:

1. Wpisana nazwa tabeli lub widoku naprawdę nie istnieje.

   • Sprawdź pisownię — może jest literówka.

   • Czy jesteś podłączony do bazy danych, w której ona istnieje? Być może korzystasz z systemu testowego, który go nie ma.

   • Zapytanie dba_objects aby sprawdzić, czy tabela istnieje w innym schemacie. (Jeśli nie masz uprawnień do wysyłania zapytań dba_objects, all_objects wymienia wszystko, do czego masz uprawnienia do przeglądania, co może być pewną pomocą).

2. Naprawdę istnieje, ale jest w innym schemacie.
   W takim przypadku istnieją dwa możliwe problemy:

   • Nie masz uprawnień, aby wysłać zapytanie. Właściciel tabeli musi grant read on xyz (zamień rzeczywistą nazwę tabeli na xyz ) do obu

     • ty

     • public (jeśli chcesz, aby wszyscy mogli zobaczyć dane, nie zawsze jest to zalecane)

     • rola które masz (ale role nie są używane przez przechowywane PL/SQL lub widoki , więc możliwe jest, że możesz wysłać zapytanie do tabeli w innym schemacie dzięki posiadanej roli, ale nadal nie będziesz w stanie utworzyć widoku lub procedury, która z nich korzysta).

   • Musisz określić schemat. Załóżmy, że chcesz zapytać o REGIONS tabela w HR ale jesteś połączony jako SCOTT . Jeśli po prostu select * from regions będzie szukać SCOTT.REGIONS , który nie istnieje. Aby to naprawić, wykonaj jedną z następujących czynności:

     • użyj hr.regions wyraźnie w zapytaniu.

     • w swoim schemacie create or replace synonym regions for hr.regions;
       Teraz za każdym razem, gdy odwołujesz się do regions , baza danych automatycznie przekieruje do hr.regions .

     • w dowolnym schemacie z uprawnieniami do tworzenia publicznych synonimów:
       create or replace public synonym regions for hr.regions;
       Teraz każdy łączący się z bazą danych będzie miał odniesienia do regions przekierowany do hr.regions , co nie zawsze jest dobrym pomysłem, ale i tak jest jedną z opcji.

     • alter session set current_schema = hr;
       Teraz domyślny schemat rozwiązywania nazw obiektów to HR a nie ten, do którego się zalogowałeś. W przypadku aplikacji, które zawsze logują się jako inny użytkownik niż ten, który jest właścicielem tabel, możesz utworzyć po wyzwoleniu logowania więc to jest zawsze ustawione. Wtedy mogą po prostu odwołać się do regions itp. bez konieczności określania schematu i bez żadnych synonimów.