Я получаю ошибки unable to resolve table в php-файлах, содержащих SQL-запросы к допустимым таблицам.
Если я Ctrl + Enter над запросом, я получаю ожидаемые результаты в консоли БД, а если я расширяю базу данных на вкладке проводника БД, я вижу таблицы.
Это не влияет на выполнение кода, но раздражает, потому что бросается в глаза при написании кода и маскирует настоящие ошибки SQL.
Я попытался обновить соединение с базой данных и убедился, что вкладка php подключается к правильной базе данных.
Попробуйте заново создать подключение к БД с нуля (удалите существующее и создайте его заново).
Думая о возможных причинах... Я могу представить такой сценарий:
Никаких других идей.
В 2017.2 мне пришлось пойти на
Настройки > Языки и платформы > Области разрешения SQL
и добавьте туда мой проект и ссылку на базу данных, чтобы снова все исправить.
Я получал то, что получал OP, и проблема заключалась в том, что моим сервером БД был MariaDB, и я выбрал MySQL в качестве диалекта SQL.
См. Файл > Настройки: Языки и платформы > Диалекты SQL.
Неисправное загрязнение ошибок ТОЖЕ МЕНЯ БЕЗУМИТ!
Если у меня начнутся проблемы с разрешением SQL, я проверю свои области разрешения (настройки -> Языки и платформы -> Области разрешения SQL).
Как правило, у меня возникает больше всего проблем, когда для сопоставления моего проекта по умолчанию установлено значение «Все источники данных».
Следующие шаги всегда исправляют это для меня:
Ваши ложные ошибки разрешения должны исчезнуть после следующего цикла синтаксического анализа.
Вы не ограничены применением описанных выше шагов только к одному соединению с БД, вы можете сделать это для всех соединений в вашем проекте.
Иногда также работает добавление пользовательской области разрешения, но для меня это случайность.
Повторное подключение к БД никогда не работает для меня.
Указание таблицы работает хорошо... но это может стать очень громоздким по мере роста проекта.
Надеюсь это поможет!
РЕДАКТИРОВАТЬ:
Я также столкнулся с дополнительной ситуацией, когда PHPStorm разрешал только некоторые из моих запросов, независимо от того, какие настройки разрешения области я использовал. Однако после того, как я прикрепил консоль к своему файлу, они разрешились просто отлично. (Выполните поиск «Прикрепить консоль» в разделе «Справка | Найти действие». Вы также можете добавить его в «Быстрый список» или привязать его к клавишам.)
Хотя этот ответ предназначен специально для phpstorm, у меня была такая же проблема в IntelliJ, и ни одно из вышеперечисленных исправлений не помогло мне. Я добавил свой прицел, все было активно. Я мог прекрасно запросить базу данных в окне консоли, и я был совершенно озадачен.
В конце концов, я заметил текст на панели базы данных, в котором крошечным текстом было написано 0 of 4. Это выглядело так:
Нажав на текст 0 of 4, я обнаружил, что к соединению не добавлено никаких схем, даже несмотря на то, что при первоначальном соединении была установлена база данных по умолчанию. Переход на эту страницу позволяет добавлять схемы. Обязательно выберите «Все схемы», «Текущая схема» или конкретную базу данных, которую вы хотите использовать с вашим подключением.
Изменен диалект на MariaDB на глобальном уровне и уровне проекта.
OR
Чтобы отклонить эту ошибку в версиях PHPStorm до 2017 года, в которых нет параметра SQL Resolution Scopes:
В моем случае сработало добавление имени базы данных перед именем таблицы.
Например, вместо SELECT * FROM Client поставьте SELECT * FROM database.Client.
Я добавлю еще один ответ, потому что для меня это была совершенно другая (неловкая) причина:
Я как-то забыл добавить имя базы данных в общие настройки источников данных (где вы также задаете хост, пользователя и пароль).
В моем случае я нажал правую кнопку в SQLScript и изменил диалект на универсальный SQL. Это сработало для меня.
Я решил эту проблему следующим образом:
SELECT * FROM user WHERE user_email='$email' AND user_password='$password'
Current Schema, оставив проверенной только правильную базу данных. В противном случае он попытается разрешить все из базы данныхinformation_schema. 04.09.2019Current Schema, и нужную мне базу данных. Я предполагаю, чтоinformation_schemaбыл текущим, но я просто указываю на это как на дополнительный шаг отладки. 04.09.2019