Таблица или представление пользователя не существует oracle
Я могу подтвердить, что таблица существует в БД, и я могу вставить данные в эту таблицу с помощью oracle разработчик sql. Но когда я пытаюсь вставить строки с помощью preparedstatement в java, его метательная таблица не существует ошибки.
пожалуйста, найдите трассировку стека ошибки ниже
Can кто-нибудь предлагает причины этой ошибки ?
обновление : проблема решена
не было никаких проблем с моими свойства подключения к базе данных или имя таблицы или представления. Решение проблемы было очень странным. Один из столбцов, который я пытался вставить, был типа Clob. Поскольку у меня было много проблем с обработкой данных clob в oracle db раньше, я попытался заменить сеттер clob временным сеттером строк и тем же кодом, выполненным без каких-либо проблемы и все строки были правильно вставлены.
ie. peparedstatement.setClob (columnIndex, clob)
peparedstatement.setString (columnIndex, "String")
почему существует таблица или представление ошибок, была вызвана ошибка при вставке данных clob. Кто-нибудь может объяснить ?
Спасибо большое за ваши ответы и комментарии.
Oracle также сообщит об этой ошибке, если таблица существует, но у вас нет никаких прав на нее. Поэтому, если вы уверены, что таблица есть, проверьте гранты.
кажется, есть какая-то проблема с setCLOB (), которая вызывает ORA-00942 при некоторых обстоятельствах, когда целевая таблица существует и правильно привилегирована. У меня сейчас есть эта точная проблема, я могу заставить ORA-00942 уйти, просто не связывая CLOB в ту же таблицу.
Я пробовал setClob () с java.язык SQL.Clob и setCLOB () с оракулом.интерфейс jdbc.Но с тем же результатом.
Как вы говорите, если вы связываете как строку, проблема уходит - но это тогда ограничивает размер данных до 4K.
из тестирования кажется, что он запускается, когда транзакция открыта в сеансе до привязки CLOB. Я вернусь, когда разберусь с этим. проверка поддержки Oracle.
не было никаких проблем с моими свойства подключения к базе данных или имя таблицы или представления. Решение проблемы было очень странным. Один из столбцов, который я пытался вставить, был типа Clob. Поскольку у меня было много проблем с обработкой данных clob в oracle db раньше, попробовал заменить сеттер clob временным сеттером строк и тем же кодом, выполненным без каких-либо проблем, и все строки были правильно вставлены.
ie. peparedstatement.setClob (columnIndex, clob)
peparedstatement.setString (columnIndex, "String")
@unbeli прав. Отсутствие соответствующих грантов в таблице приведет к этой ошибке. Как бы то ни было, я недавно испытал это. Я испытывал точную проблему, которую вы описали, я мог бы выполнить инструкции insert через SQL developer, но потерпел бы неудачу при использовании hibernate. Я, наконец, понял, что мой код делает больше, чем очевидная вставка. Включение в другие таблицы, не имеющие соответствующих субсидий. Настройка привилегий grant решила это для мне.
Примечание: у вас нет репутации для комментариев, иначе это может быть комментарий.
Я нашел, как решить эту проблему без использования метода setString() JDBC, который ограничивает данные 4K.
что вам нужно сделать, это использовать preparedStatement.setClob (int parameterIndex, reader reader). По крайней мере, это сработало для меня. Мысль Oracle drivers преобразует данные в поток символов для вставки, похоже, нет. Или что-то конкретное, вызывающее ошибку.
С помощью characterStream, кажется, работает для меня. Я читаю таблицы из одной БД и пишу другой использует jdbc. И я получал таблицу, не найденную ошибку, как указано выше. Так вот как я решил проблему:
теперь все хорошо.
мы столкнулись с этой проблемой в столбце BLOB. На случай, если кто-то еще приземлится на этот вопрос при возникновении этой ошибки, вот как мы решили проблему:
мы начали с этого:
мы решили проблему, изменив эту строку на это:
ваш скрипт предоставляет название схемы, или вы полагаетесь на пользователя, вошедшего в базу данных, чтобы выбрать схемы по умолчанию?
возможно, вы не называете схему и выполняете пакет с системным пользователем вместо пользователя схемы, что приводит к неправильному контексту выполнения для сценария, который будет работать нормально, если выполняется пользователем, у которого целевая схема установлена в качестве схемы по умолчанию. Ваши лучшие действия будут включать имя схемы в операторах insert:
обновление: вы пытаетесь связать имя таблицы как связанное значение в подготовленном операторе? Это не сработает.
это работает для меня:
здесь я получил решение для вопроса. Проблема в стеклянной рыбе, если вы ее используете. При создании имени JNDI убедитесь, что имя пула правильно, а имя пула-это имя созданного пула соединений.
Насколько я знаю, есть три основные причины ошибки ora-00942:
- Недостаточно прав пользователя
- Таблица или представление на самом деле не существуют
- Таблица или представление находятся в другой схеме
Я покажу вам, как обратиться к каждому.
Исправьте ошибку ora-00942
Прежде всего, небольшой отказ от ответственности. Я не администратор баз данных, я администратор Windows, а также специалист по аппаратному и настольному оборудованию. Я знаю, как запустить SQL, но не до какой-то степени опыта и, конечно, не до уровня, который может устранять проблемы. Я должен был попросить моего друга Oracle DBA о помощи, поэтому, пока я писал эту часть, все умные биты принадлежали ему.
Этот список из трех причин ошибки ora-00942 не является исчерпывающим. Есть, очевидно, другие случайные причины этого, но эти три, по-видимому, наиболее распространены.
8 Answers 8
You can set an EVENT in your parameter file (plain text or spfile) to force Oracle to dump a detailed trace file in the user_dump_dest, the object name might be in there, if not the SQL should be.
EVENT="942 trace name errorstack level 12"
If you are using a plain text file you need to keep all your EVENT settings on consecutive lines. Not sure how that applied to spfile.
I tried to add this line to "init.ora" file, then restarted my dbms, but nothing was available in the user_dump_dest folder. Any tips, please?
SQL*Plus does tell you the table that doesn't exist. For example:
Here it shows that the name of the missing table and the line number in the SQL statement where the error occurs.
Similarly, in a one-line SQL statement you can see the asterisk highlighting the name of the unknown table:
In terms of your question, I guess the reason the error message doesn't include the name of the table is that the error message itself needs to be static text. The line number and location in the line of the error is clearly passed back to SQL*Plus (somehow).
This is fine when you can use SQL*Plus interactively to test your queries. A common case, however, is when you only have a log from an application using a persistence layer like Hibernate and it is difficult to correlate exactly what query might have been executed.
@erickson: I'm afraid it is a limitation of the thin JDBC driver. OCI call OCIErrorGet can return more than one error string. The 1st one is main the others are details (like a stacktrace). You can also ask an "error handle" to get details like OCI_ATTR_PARSE_ERROR_OFFSET. I can not find any corrending calls in JDBC driver API. Anyway Oracle JDBC driver throws pure generic JDBC SqlExption - nothing Oracle specific.
I would disagree with the opinion, that SQL+ lets you understand which table name is unacceptable. True, it helps in direct DML, although parsing it is very hard. But when it comes to dynamic, we get no help:
If you are using a SQL browsing tool like TOAD or TORA it will help you with ORA errors by highlightling or pointing moving the cursor to where you made your error.
Copy and paste your SQL in to one of these tools to help. You may also find the analyse info available useful too.
If its not a huge statement, then the easiest way is just to check the data dictionary,
This isn't ideal, but short of going and examining trace files, I'm not sure how else to do it.
I've never had a problem with interpreting Oracle error messages. Part of the reason is that every interactive tool I've seen for developing SQL for Oracle helpfully points to the location the query went wrong. That includes SQL*Plus, as others have noted, and the Perl DBI module:
Well, that is a bit hard to read since it's all squished on one line. But a GUI tool would be able to point to the token where Oracle started having problems with the query. And given a bit of work on a parser, you could write a tool to pick out the offending table.
To answer the underlying question, Oracle errors don't seem to be designed to work the way you expect. As far as I can tell, none of the the error messages in Oracle support variable text. Instead, Oracle returns two bits of information: an error number and a location where the error occurs. If you have proper tools, it's pretty easy to diagnose an error with those pieces of data. It can be argued that Oracle's system is nicer to tool creators than one which provides variable amounts of diagnostic data depending on the error. Imagine having to write a custom parser for all of Oracle's error messages (including future errors) to highlight the offending location.
Sometimes including the table name would be misleading. Just knowing where things went wrong can be a huge help:
As for why Oracle chose to do thing this way, I have some speculations:
IBM used this style of error message for System R, which Larry Ellison, Bob Miner and Ed Oates copied to build Oracle V2. (Backward compatibility.)
Error number and location are the smallest possible representation of diagnostic information. (Parsimony.)
As I indicated above, to simplify the creation of tools that connect to Oracle. (Interoperability.)
In any case, I don't think you need to be a DBA to figure out which table doesn't exist. You just need to use the proper tools. (And adjust your expectations, I suppose.)
Я использую SQL-разработчик, и я создал соединение с моей базой данных с системным пользователем после того, как создал пользователя и сделал другое соединение с этим пользователем со всеми необходимыми привилегиями.
Но когда я пытаюсь продолжить выполнение, я получаю ошибку SQL
Таблица или представление ORA-00942 не существует.:
Недостаточно прав пользователя
Одной из основных причин ошибки ora-00942 является то, что у пользователя недостаточно прав для доступа к рассматриваемой таблице. Вы можете проверить это, выполнив два запроса.
— список привилегий объекта для пользователя или роли
Эти двое скажут вам, имеет ли данный пользователь правильные привилегии для запуска команды. Если пользователь имеет правильные привилегии, переходите к следующему. Если пользователь не имеет правильных привилегий, предоставьте их им или попросите администратора БД сделать это.
Ошибка ora-00942 также может возникнуть, если пользователь используемой схемы имеет привилегии INSERT, но не привилегии SELECT. Опять же, проверьте уровень привилегий и добавьте SELECT в список или попросите администратора БД сделать это. Очевидно, что каждой схеме должна быть предоставлена определенная привилегия SELECT, в противном случае вы все равно увидите ошибку ora-00942.
ОТВЕТЫ
Ответ 1
Поскольку этот пост является верхним, найденным в stackoverflow при поиске "ORA-00942: таблица или представление не существует вставки", я хочу упомянуть еще одну возможную причину этой ошибки (по крайней мере, в Oracle 12c): таблица использует последовательность для установки значения по умолчанию, и пользователь, выполняющий запрос вставки, не имеет привилегии выбора в последовательности. Это была моя проблема, и мне потребовалось слишком много времени, чтобы понять это.
Чтобы воспроизвести проблему, выполните следующий SQL как user1 :
Затем выполните этот оператор insert как user2 :
Результат будет "ORA-00942: таблица или представление не существует", хотя user2 имеет вставку и выбор привилегий в таблице user1.customer и корректно префикс таблицы с именем владельца схемы. Чтобы избежать этой проблемы, вы должны предоставить привилегию выбора в последовательности:
Ответ 2
либо пользователь не имеет привилегий, необходимых для просмотра таблицы, таблица не существует или вы выполняете запрос в неправильной схеме
существует ли таблица?
какие привилегии вы предоставили?
выполняется ли запрос от владельца с первого запроса?
Ответ 3
Вы не можете напрямую обращаться к таблице с именем "клиент". Либо он должен быть "user1.customer", либо создать синоним "клиент" для user2, указывающий на "user1.customer". надеюсь, что это поможет.
Ответ 4
Ответ 5
Чувствительные к регистру таблицы (имена таблиц, созданные в двойных кавычках) также могут выдавать ту же ошибку. Смотрите этот ответ для получения дополнительной информации.
когда у меня есть оператор sql, например select * from table1 , он отлично работает, но как только я помещаю его в функцию, я получаю:
есть несколько вещей, которые вы могли бы посмотреть. Основываясь на вашем вопросе, похоже, что владелец функции отличается от владельца таблицы.
1) предоставляет через роль: для создания хранимых процедур и функций на объектах другого пользователя требуется прямой доступ к объектам (вместо доступа через роль).
по умолчанию хранимые процедуры и методы SQL выполняются с помощью привилегии их владельца, а не их текущий пользователь.
Если вы создали таблицу в схеме A и функцию в схеме B, вы должны взглянуть на концепции прав вызывающего/Определителя Oracle, чтобы понять, что может вызвать проблему.
существует большая вероятность того, что привилегии для выбора из таблицы 1 были предоставлены роли, и роль была предоставлена вам. Права, предоставленные роли, недоступны для PL / SQL, написанного пользователем, даже если пользователю была предоставлена роль.
вы видите это много для пользователей, которым была предоставлена роль dba для объектов, принадлежащих sys. Пользователь с ролью dba сможет, скажем, SELECT * from V$SESSION , но не сможет написать функцию, которая включает SELECT * FROM V$SESSION .
исправление заключается в предоставлении явных разрешений на рассматриваемый объект непосредственно пользователю, например, в случае выше, пользователь SYS должен GRANT SELECT ON V_$SESSION TO MyUser;
убедитесь, что функция находится в той же схеме БД, как таблицы.
либо у вас нет разрешения на эту схему / таблицу, либо таблица существует. В основном эта проблема возникает при использовании других таблиц схемы в хранимых процедурах. Например. Если вы используете хранимую процедуру из user/schema ABC и в том же PL/SQL есть таблицы, которые из user / schema XYZ. В этом случае ABC должна иметь GRANT т. е. привилегии таблиц XYZ
предоставить все на ABC;
очень простое решение-добавить имя базы данных с именем таблицы, например, если ваше имя БД DBMS и таблицы info тогда это будет DBMS.info для любого запроса.
Таблица или представление на самом деле не существуют
Причиной ошибки ora-00942 может быть неправильный синтаксис запроса или отсутствие таблицы. Хотя это может показаться логичным для начала, я уверен, что привилегия пользователя является причиной ошибки номер один. Таблица, которой там нет или используется неверный синтаксис таблицы, занимает второе место.
Чтобы проверить, существует ли таблица, сначала проверьте синтаксис запроса. Если синтаксис правильный, запустите этот запрос.
В последней строке вставьте фактическое имя таблицы, где вы видите «YOUR_TABLE_NAME». Это должно точно сказать вам, существует ли таблица, к которой вы пытаетесь обратиться, или нет. Если он возвращается без таблицы, запрашиваемая вами таблица не существует в схеме или базе данных.
Если в используемой вами системе есть меню «Таблицы», вы можете вручную проверить таблицу, если хотите, но вышеуказанный запрос выполняет свою работу.
Таблица или представление находятся в другой схеме
Если у пользователя есть права, и таблица существует, но вы все еще видите ошибку ora-00942, скорее всего, это связано со схемой. Если вы управляете несколькими схемами, легко выполнить запрос к схеме, которая не принадлежит вам. Когда вы заняты и против этого, это простая ошибка, чтобы сделать.
Проверьте схему вручную, если можно или добавьте имя схемы в строке ОТ вашего запроса. Если у вас нет правильных привилегий для новой схемы, вы снова увидите ошибку ora-00942. Вернитесь к первому исправлению привилегий пользователя и проверьте соответствующую схему или попросите своего администратора базы данных сделать это за вас.
Как упомянуто выше, я проконсультировался с моим приятелем по DBA Oracle для этой работы, так что вся заслуга ему в тяжелой работе. Если вы обнаружите здесь какие-либо ошибки или упущения, они одни. Дайте мне знать в разделе комментариев, если я что-то пропустил или ошибся, и я исправлю это.
If you've used Oracle, you've probably gotten the helpful message "ORA-00942: Table or view does not exist". Is there a legitimate technical reason the message doesn't include the name of the missing object?
Arguments about this being due to security sound like they were crafted by the TSA. If I'm an attacker, I'd know what table I just attempted to exploit, and be able to interpret this unhelpful message easily. If I'm a developer working with a complex join through several layers of application code, it's often very difficult to tell.
My guess is that when this error was originally implemented, someone neglected to add the object name, and now, people are afraid it will break compatibility to fix it. (Code doing silly things like parsing the error message will be confused if it changes.)
Is there a developer-friendly (as opposed to recruiting your DBA) way to determine the name of the missing table?
Although I've accepted an answer which is relevant to the topic, it doesn't really answer my question: Why isn't the name part of the error message? If anyone can come up with the real answer, I'll be happy to change my vote.
I imagine you'd have to ask an actual Oracle engineer to get the real answer. Incidentally, I work for Sybase, and our server (SQL Anywhere) gives you "Table 'blah' not found".
Well I totally agree with the poster. It has cost me hours of time trying to find development issues because oracle neglects to say what table did not exist! And security? You could still opt NOT to pass the detailed error message to the client which you normally NEVER do! I usually find Oracle software really bad when it comes to thinking a little further than the obvious.
Читайте также: