Bitrix ошибка соединения с сервером баз данных: Как исправить ошибку 1045 в MySQL

Как исправить ошибку 1045 в MySQL

При работе с системой MySQL могут возникнуть самые разные ошибки, и на этапе освоения программы разобраться с ними может быть сложно. Одна из наиболее распространенных проблем — ошибка 1045, которая сопровождается сообщением Access denied for user ‘root’@’localhost’ (Using password: YES и NO). Сегодня я расскажу, как ее исправить.

Понять суть проблемы можно, переведя сообщение об ошибке на русский язык. Означает оно, что пользователю с именем root на машине localhost запрещен доступ к БД при использовании пароля или без него.

Ошибка 1045 возникает из-за запрета доступа к базе данных

Причины ошибки Access denied for user ‘root’@’localhost’

Чтобы свободно получить доступ в MySQL, должно совпасть три параметра, описывающих пользователя базы данных — имя, название машины и пароль. Если есть какие-то несовпадения, доступ будет запрещен. Самая простая причина проблемы — неправильный ввод пароля. Кроме этого, вызывать ошибку может неправильный синтаксис.

В системе MySQL нет простой зависимости имя пользователя – пароль, название хоста играет важную роль в получении доступа к БД. Оно может иметь вид IP-адреса, доменного имени, ключевого слова (например, localhost) или символа, объединяющего несколько машин в группу (например, % — любой хост, кроме локального).

Ошибка имеет ключ (Using password: NO) при входе в БД через браузер

Наиболее распространенные ошибки при обращении к БД:

1. При присвоении прав новому пользователю не был указан адрес машины, с которой он может подключаться. В таком случае ему автоматически будет разрешено пользоваться БД с любого хоста, кроме локального, и при попытке подключения с localhost возникнет ошибка доступа.
2. Неправильно расставленные кавычки. Если при создании пользователя написать ‘username@localhost’, это будет значить, что username@localhost может подключаться с любой машины, кроме локальной, а не что username может подключаться с компьютера localhost. Логин пользователя и имя машины должны иметь свою пару кавычек.
3. Использование пароля при его отсутствии в базе данных.

В зависимости от того, при каком способе подключения к БД возникает ошибка Access denied for user ‘root’@’localhost’ (Using password: YES или NO), используются разные методы решения проблемы.

Как исправить ошибку 1045 в MySQL

Если ошибка Access denied for user ‘root’@’localhost’ (Using password: YES и NO) появляется с указанием Using password: YES, проблема заключается в неправильном вводе пароля. Проверить это можно, открыв таблицу mysql.user, в которой хранятся данные обо всех пользователях.

В таблице mysql.user хранятся данные для входа пользователей

Порядок действий таков:

1. Откройте таблицу пользователей.
2. Проверьте, существует ли пользователь root с хостом localhost. Если он есть, смотрите на поле «password». Если там пусто, зайти в базу можно без ввода пароля. Если там что-то есть, значит, вы вводите неправильный пароль.
3. Смените пароль командой SET PASSWORD.
4. Если пользователя root нет, создайте его, установите пароль и предоставьте ему права.

После этого в базу данных можно зайти. Если изменить данные не получается, следует использовать параметр —skip-grant-tables, который отменяет все настройки разрешений.

Строки, которые нужно изменить в файле конфигурации

Если ошибка появляется с ключом (Using password: NO), нужно сделать следующее изменить файл config.inc.php, указав в нем правильные данные. Если проблема возникает при установке MySQL, нужно удалить базы данных старой версии программы или сменить пароль для доступа к ним, используя режим —skip-grant-tables.

Таким образом, ошибка Access denied for user ‘root’@’localhost’ (Using password: YES или NO) возникает при несоответствии пароля и имени пользователя и легко исправляется заменой данных для входа.

Как заставить Сервер 1С увидеть в сети сервер PostgreSQL

Как заставить Сервер 1С (что работает на Windows), увидеть в сети сервер PostgreSQL на Linux UBUNTU?

Конечно, данная тема также подымается и на курсе: Администратор 1С!

Собственно решить такие проблемы как:

• “Ошибка создания информационной базы”
• “Ошибка операции администрирования”
• “Сервер баз данных не обнаружен”
• “Could not connect to server: Connection refused (Ox. .00000/0000…)
• Is the server running on host 192.168….x… and accepting TCP/IP connections on port 5432?”

При установке на один физический сервер, “Cервера 1С” (кластер серверов) + СУБД PostgreSQL  проблем обычно не возникает. И “Сервер 1С” прекрасно видит PostgreSQL, новые информационные базы создаются, и все работает по умолчанию, конечно если поставили птичку во время установки СУБД на Windows – “Разрешать подключения с любых IP адресов”.

Но совсем другая история, когда PostgreSQL у нас работает на Linux!

Ведь в процессе установки PostgreSQL на Linux подобных “птичек” нет )

Как решить проблему?

На самом деле все довольно просто!

Проверим в начале c какого IP принимаются подключения, и какой порт слушает сервис PostgreSQL.

Тут нам поможет команда:

sudo netstat -pant | grep postgres

На картинке ниже, мы четко видим, что наш PostgreSQL слушает только localhost – 127. 0.0.1 и порт по умолчанию 5432.

Выражаясь простым языком, “Сервер 1С” может работать в паре с СУБД, только на этом севере (хосте), при текущих настройках (По умолчанию, после установки “Постгреса” на этот сервер).

И так, теперь разобравшись, что проблема действительно есть в настройках PostgreSQL, можно приступить к ее решению! 

Сперва нам нужно найти конфигурационный файл postgresql.conf

Местоположение этого файла зависит от версии СУБД PostgreSQL (На примере использую сборку от компании Postgres Professional – PostgreSQL 10.5, сборку установил на UBUNTU server 18.04 LTS).

Найти файл очень просто, используем команду:

ps aux | grep postgres | grep -- -D

Нас интересует все что мы видим после -D  /var/lib/pgpro/1c-10/data/

Здесь в каталоге /data/ и лежит наш файл postgresql.conf

Идем в этот каталог, откроем для редактирования postgresql.conf, и внесем нужные правки.

Для передвижения по каталогам и редактированию файлов на UBUNTU server 18.04, я использую MC (Midnight Commander).

Как его установить, писал здесь >>

(Выбрав файл postgresql.conf) давим клавишу F4.

Ищем строку #listen_addresses = ‘localhost’.

Раскомментируем строку (убрав #).

И приведем строку к виду: listen_addresses = ‘*’

Давим F2 + Enter и сохраняем файл.

Далее выполним перезапуск сервиса postgresql:

Стоп:

service postgrespro-1c-10 stop

И старт:

service postgrespro-1c-10 start

(Команда перезапуска у Вас будет отличатся, если версия PostgreSQL другая или другой сборки).

Затем стоит проверить работает ли PostgreSQL:

service postgrespro-1c-10 status

И если видим (как на картинке ниже) зеленым цветом active (running) значит PostgreSQL работает!

Смотрим, что теперь “слушает” PostgreSQL:

sudo netstat -pant | grep postgres

Отлично!

После перезапуска сервиса, PostgreSQL принимает подключения действительно с любых IP адресов на стандартный порт 5432!

Но!  не спешите сейчас бежать на Сервер 1С, создавать новую информационную базу, или выполнять подключение.

Сервер 1С встретит Вас новой ошибкой! )

“ВАЖНО: в pg_hba.conf нет записи для компьютера “192.168.128.13”, пользователя “postgres”, базы “template1″, SSl выкл.”

Сервер 1С требует от нас создать еще одну запись, уже в другом файле pg_hba.conf

“Надо, так надо )”

Открываем для редактирования файл pg_hba.conf, он к слову находится в том же каталоге, что и файл postgresql.conf

Ищем строку: host      all          all                  127.0.0.1/32      md5

И приводим к виду: host      all          all                  192.168.128.13/24      md5

Где 192.168.128.13 ip адрес нашего Сервера 1С. (Тот сервер, где работает Сервер 1С).

Кстати! можно поступить и по-другому.

Просто добавить в строке ниже еще одну запись (Ту которую от нас и требует Сервер 1С):

Вот и все!

Сохраним файл и выполним перезапуск PostgreSQL.

Теперь новая информационная база 1С, будет создана успешно!

Сервер 1С работает на Windows, а PostgreSQL на Linux!

Если Вы хотите больше узнать о технической стороне 1С, тогда регистрируйтесь на первый бесплатный модуль курса: Администратор 1С >>>

Ошибка соединения с базой данных SQL Server или как настроить брандмауэр для доступа к порту 1433 по протоколу TCP

Ошибка соединения с базой данных при регистрации программы.

— Настройка брандмауэра. Доступ по протоколу TCP через порт 1433.

При попытке
зарегистрировать лицензию на программу Смета 2007, может возникнуть ситуация, при которой вы увидите такое сообщение:

Сообщение об ошибке при отсутствии соединения с базой данных.

Дело в том, что в процессе регистрации, программа пытается установить соединение с базой данных SQL Server, находящейся на нашем сервере. Перед началом регистрации программа проверяет доступность соединения с этой базой данных и,
в случае, если установить соединение не удаётся, выводит это сообщение, в котором и указаны возможные причины возникновения этой ошибки.

— Первая причина, думаю, всем понятна и не требует комментариев.

— Со второй причиной — «Удалённый сервер недоступен» — вы ничего поделать не
можете, т.к. она имеет место быть тогда, когда возникают какие-то проблемы на
нашем сервере, что, кстати, случается крайне редко.  В этом случае следует
просто подождать какое-то время и попытаться снова.

— Третья причина — «Брандмауэр или антивирус блокирует доступ по протоколу TCP через порт 1433» — это основная и самая распространённая причина, по которой вы
можете увидеть вышеприведённое сообщение.

Небольшая справка:
Клиентские системы используют порт TCP 1433 для подключения к системе управления базами данных SQL Server. TCP 1433 — порт, выбираемый для SQL Server по умолчанию.
Это официальный номер сокета IANA (агентство по выделению имен и уникальных параметров протоколов Интернета) для SQL Server.

Остановимся на этой причине подробнее и рассмотрим, на примере брандмауэра антивирусной программы Dr. Web, как настроить брандмауэр, чтобы он не блокировал нашей
сметная программа возможность выполнить необходимые действия.

Настройка брандмауэра. Доступ по протоколу TCP через порт 1433.

Откройте окно «Настройки», антивируса Dr. Web

Окно «Настройки» антивируса Dr. Web.

выберите пункт «Компоненты защиты», далее «Брандмауэр» и кликните на ссылке «Изменить доступ к сети для приложений».

Окно «Брандмауэр» антивируса Dr. Web.

Откроется окно «Приложения», в котором вы увидите список программ, для которых
определены некие «правила доступа к сетевым ресурсам».

Окно «Приложения» брандмауэра Dr. Web.

Нас интересует программа «EXCEL.EXE», которая должна быть в списке. Кроме того,
для этой программы должно быть настроено правило, которое, так или иначе,
разрешает программе EXCEL получать доступ к базе данных SQL Server через порт
1433 по протоколу TCP. 

Подчеркну, НЕ программа Смета 2007 должна иметь доступ, а именно программа Excel, т.к.
программа для составления смет Смета 2007 работает «внутри» Excel.

Если приложение EXCEL.EXE в списке присутствует, дважды кликните на нём,
чтобы открыть окно «Редактирование набора правил для EXCEL.EXE»:

Окно «Набор правил для приложения EXCEL.EXE».

Как видите, в данном случае, для приложения определено всего одно правило, причём,
оно сформировано брандмауэром автоматически и блокирует какие-то
пакеты.

Дважды кликните на этом правиле и, в открывшемся окне «Редактирование правила»,
установите настройки так, как показано на рисунке:

Окно «Редактирование правила для приложения».

Установите Действие: «Разрешать пакеты»,  Тип соединения достаточно
установить как «Исходящее». Правило разрешает соединения как по протоколу TCP
(что нам и нужно), так и по протоколу UDP и, нужный нам порт — 1433 — находится
внутри разрешённого диаппазона (от 1025 до 65535). Нажмите Ок, чтобы сохранить
настройки.

Если же вы не нашли в списке приложения «EXCEL.EXE», его нужно добавить, и
определить для него соответствующее правило, например так:

Окно «Новое правило для приложения».

Как видите, это правило разрешает соединения для приложения EXCEL.EXE только
через нужный нам порт.

Случается так: и правило есть, и соединение оно вроде бы не блокирует, а
соединения, тем не менее, нет! В этом случае может помочь следующее: удалите
существующее правило и добавьте новое, определите настройки (пусть те же самые)
и сохраните изменения. В итоге, вроде бы, сделали всё то же самое, но, тем не
менее, всё начинает работать.

В брандмауэрах от других производителей, подобные настройки, думаю, производятся
аналогичным образом.

Блокировать доступ может и встроенный брандмауэр Windows. Проверьте, включён ли
он и каковы его настройки.

Не зависимо от используемого брандмауэра, суть остаётся одна:
для приложения EXCEL должен быть открыт порт 1433 по протоколу TCP!

Невозможно подключиться к серверу базы данных, невозможно запустить указанную базу данных

Задача

В этом техническом примечании даются советы по поиску и устранению ошибок типа «невозможно подключиться к базе данных» при использовании Sybase SQL Anywhere IBM® Rational® ClearQuest®.

Признак

Эта ошибка появляется при попытке подключиться к клиенту ClearQuest к серверу SQL Anywhere, который находится в другой подсети от сервера, или при использовании удаленного доступа к сети.

SQLDriverConnect: RETCODE = -1, State = 08001, Native Error = 82
SQL Anywhere - невозможно подключиться к серверу базы данных: невозможно запустить указанную базу данных.

Причина

И сервер SQL Anywhere, и клиент по умолчанию отправляют широковещательные пакеты по сети при запуске. Эти пакеты либо теряются, либо перенаправляются неправильно, когда они проходят через сетевой маршрутизатор, который соединяет одну или несколько подсетей.Поскольку клиент не может принимать широковещательные сообщения сервера, он думает, что сервер не существует.

Решение проблемы

Существует несколько уровней устранения неполадок для решения этой проблемы.

Проверяйте соединение после каждого шага ниже и не удаляйте никакие настройки во время процесса. После того, как соединение установлено, нет необходимости выполнять какие-либо дальнейшие действия.

Уровень 1 — Добавьте сумматоры IP или имя хоста сервера базы данных в параметры подключения инструмента обслуживания.

Указание IP-адреса сервера SQL_Anywhere в поле ввода Host при попытке подключения к схеме с помощью ClearQuest Maintenance Tool.

ИЛИ

Убедитесь, что cqdbinfo.ini для каждой базы данных (главной и пользовательской), расположенной в каталоге на сервере базы данных, где находится физическая база данных, имеет параметр QDBConnectHosts =, установленный на имя хоста сервера или IP-адрес. Если нет, добавьте имя или IP-адрес сервера SQL Anywhere и перезапустите сервер.

Уровень 2 — Отключить трансляцию на сервере

1. На компьютере, на котором размещен SQL Anywhere, выберите:
   Пуск> Программы> Сервер базы данных Sybase SQL Anywhere 5.5.05> Sybase Central , затем выберите папку Services .
2. Имя службы, созданной для работы с ClearQuest, должно появиться в правом окне. Щелкните правой кнопкой мыши службу и выберите СТОП .
3. Щелкните правой кнопкой мыши еще раз и перейдите в свойства службы.
4. На вкладке конфигурации в окне «Параметры исполняемого файла» добавьте {dobroadcast = no; host = dbservermachinename} к параметру TCPIP.
   Например, если имя сервера базы данных — «george», то полная командная строка будет выглядеть так:
   
-n cqsqlany -c 2040 -tl 0 -ti 7200 -x TCPIP {dobroadcast = no; host = george}

   
   IP-адрес также может применяться вместо имени хоста, если сервер базы данных использует статический IP-адрес, а не DHCP.

5. Проверить соединение.

Уровень 3 — Отключить трансляцию на стороне клиента
Соединение с сервером можно проверить с помощью программы Sybase dbclient, расположенной в каталоге рациональный / sqlany50 / win32.
Если это соединение не удается, соединение ClearQuest также не работает.
Клиентское соединение принимает значения по умолчанию Sybase, чтобы имитировать то, что ClearQuest будет использовать, предоставив имя службы dbclient.

Это проиллюстрировано в следующем примере, где служба Sql Anywhere называется cqsqlany:

C: \ program files \ рациональная \ sqlany50 \ win32> dbclient cqsqlany

Если это не удается, добавьте nobroadcast и выполните следующие действия:

… \ win32> dbclient cqsqlany -x tcpip {dobroadcast = no; host = george}

Если теперь подключается dbclient, попробуйте подключиться с помощью клиента ClearQuest (оставив окно dbclient открытым).

Если это работает, то переменная среды может быть установлена ​​на каждом клиенте, который включает параметры клиентского соединения, так что нет необходимости запускать dbclient вручную. Значение этой переменной среды добавляется к команде dbclient для запуска клиентского соединения и переопределяет протоколы и конфигурацию хостов, заданную в свойствах базы данных CQ.

В частности, чтобы отключить широковещательную передачу для TCPIP:

установите CQ_SA_OPTIONS = -x TCPIP {dobroadcast = no; host = }

Где — это имя сетевого хоста компьютера, на котором установлен SQL Anywhere это работает; это также может быть IP-адрес.

Примечание. Отключение широковещательной рассылки на стороне сервера Sql Anywhere (уровень 2) также может помочь, если служба Sql Anywhere не запускается.

Уровень 4 — Сбросить информацию о подключении

Удалив файл asasrv.ini, служба SQL Anywhere создаст новый файл asasrv.ini, содержащий информацию, указанную вами в строке подключения. Файл asasrv.ini обычно находится в каталоге исполняемых файлов SQL Anywhere. Например, каталог по умолчанию для SQL Anywhere 8 — C: \ Program Files \ Rational \ SqlAnywhere8 \ win32. Этот файл также может существовать в системных каталогах Windows и Windows.

[{«Продукт»: {«код»: «SSSH5A», «ярлык»: «Rational ClearQuest»}, «Бизнес-подразделение»: {«код»: «BU053», «ярлык»: «Облачная платформа и платформа данных»} , «Компонент»: «Конфигурация базы данных \ / Подключение — SQL Anywhere», «Платформа»: [{«код»: «PF033», «метка»: «Windows»}], «Версия»: «2003.06.00; 2003.06. .12; 2003.06.13; 2003.06.14; 2003.06.15 «,» Редакция «:» «,» Направление деятельности «: {» code «:» LOB15 «,» label «:» Интеграция «}}]

Ошибка подключения — pgAdmin 4 4.28 документация

При подключении к серверу PostgreSQL вы можете получить сообщение об ошибке. если ты
при появлении сообщения об ошибке внимательно прочтите его; каждая ошибка
сообщение пытается включить информацию, необходимую для решения
проблема. Для получения дополнительных сведений о конкретных ошибках найдите ошибку
сообщение в списке ниже:

Соединение с сервером потеряно

Это сообщение об ошибке указывает на то, что попытка подключения заняла больше, чем
указанный порог; может быть проблема со свойствами подключения
предоставляется в диалоговом окне Сервер , проблемы с сетевым подключением или сервер может
не работать.

не удалось подключиться к серверу: в соединении отказано

Если pgAdmin отображает это сообщение, это может быть по двум причинам:

По соображениям безопасности сервер PostgreSQL «из коробки» не слушает
Порты TCP / IP. Вместо этого он должен быть включен для прослушивания запросов TCP / IP. Этот
можно сделать, добавив listen_addresses = ’*’ ; это заставит сервер принять
подключения на любом IP-интерфейсе.

Дополнительную информацию см. В документации PostgreSQL о
конфигурация времени выполнения.

FATAL: нет записи pg_hba.conf

Если pgAdmin отображает это сообщение при подключении, с вашим сервером можно связаться
правильно по сети, но не настроен для приема вашего подключения.
Ваш клиент не был обнаружен как законный пользователь базы данных.

Для подключения к серверу файл pg_hba.conf на сервере базы данных должен быть
настроен на прием подключений от хоста клиента pgAdmin. Изменить
файл pg_hba.conf на хосте сервера базы данных и добавьте запись в форме:

Дополнительную информацию см. В документации PostgreSQL о
аутентификация клиента.

FATAL: ошибка аутентификации пароля

Ошибка аутентификации пароля для пользователя Сообщение об ошибке указывает на то
может быть проблема с паролем, который вы ввели. Повторите пароль для подтверждения
вы ввели правильно. Если сообщение об ошибке возвращается, убедитесь, что у вас есть
правильный пароль, что у вас есть право доступа к серверу, и что
доступ был правильно настроен в postgresql.conf сервера
Файл конфигурации.

[KB5852] Ошибка «Ошибка входа, сбой подключения с состоянием« Не подключен »» в ESET Remote Administrator (6.х)

Вышла новая версия

Версия 7 бизнес-продуктов ESET была выпущена 16 августа 2018 г. Эта статья относится к версии 6.x и ESET Remote Administrator. Для получения информации о новых возможностях последней версии и способах обновления см. Следующую статью:

Для устранения проблемного компонента можно отследить процесс связи следующим образом:

• Для ошибки «Ошибка входа: ошибка связи»: существует проблема со связью между вашим браузером и веб-сервером .
• Для ошибки «Ошибка входа: сбой подключения с состоянием« Не подключено »»: существует проблема с подключением между веб-сервером и ERA Server или ERA Server и ERA Database (но подключение между браузером и веб-сервером вероятно работает).

I. Устранение проблем с подключением

Начните с шага 1 и переходите к следующему шагу, пока проблема не будет решена. После завершения каждого шага обновляйте веб-консоль ERA и попробуйте снова войти в систему. .

Только для пользователей Windows

Следующие шаги содержат инструкции по решению этой проблемы в операционной системе Windows. Пользователи Linux могут следовать этим инструкциям, но инструкции по перезапуску службы и чтению файлов журналов отличаются. Дополнительные сведения см. В Руководстве пользователя ERA.

1. Проверьте наличие возможных проблем или конфликтов в вашей сети. Например, если сервер базы данных работает на другом компьютере, соединение может быть прервано.
2. Перезапустите службу Apache Tomcat.

   Apache Tomcat может занять несколько минут, чтобы начать прослушивание, даже если служба работает. Подождите несколько минут и попробуйте войти снова.

Будьте осторожны при перезапуске служб

Мы рекомендуем перезапускать службы только при необходимости и устанавливать период обслуживания, чтобы минимизировать риск потери данных.

3. Возможно, служба базы данных (SQL Server или MySQL) не запущена.Попробуйте подключиться к базе данных; если соединение с базой данных не работает , перезапустите службу базы данных.
4. Возможно, сервер ESET Remote Administrator (ERAS) не запущен.

5. Возможно, порты прослушивания уже используются (443, 2222, 2223 или 8443) и препятствуют правильной работе служб ERA. См. Часть II здесь: Проверьте возможные конфликты портов.

6. Найдите возможные ошибки в файлах журнала ERA Server и Apache Tomcat.
   • Сервер ERA:
     C: \ ProgramData \ ESET \ RemoteAdministrator \ Server \ EraServerApplicationData \ Logs \
   • Apache Tomcat:
     C: \ Program Files \ Apache Software Foundation \ Tomcat 7.0 \ Logs \

Если вам по-прежнему не удается войти в веб-консоль ERA, перейдите к части II ниже.

II. Переустановите веб-консоль ERA

Выполнение следующих инструкций может занять от десяти до двадцати (10-20) минут в зависимости от вашего сетевого подключения.

1. Остановите службу Apache Tomcat 7 из services. msc или перейдите в каталог % TOMCAT_HOME% \ bin (например, C: \ Program Files \ Apache Tomcat \ Tomcat7 \ bin ) и дважды -нажмите tomcat7w.exe .
2. Переименуйте % systemdrive% \ Program Files \ Apache Software Foundation \ Tomcat7 \ Webapps \ era в era.old .
3. Загрузите последний файл era.war из следующего места:
4. Переименуйте файл.war в era.zip (возможно, потребуется подтвердить изменение расширения имени файла), щелкните файл правой кнопкой мыши и извлеките его содержимое в следующее место:
   • % systemdrive% \ Программные файлы \ Apache Software Foundation \ Tomcat7 \ Webapps \
5. Восстановить этот файл % systemdrive% \ Program Files \ Apache Software Foundation \ Tomcat7 \ Webapps \ era.old \ WEB-INF \ classes \ sk \ eset \ era \ g2webconsole \ server \ modules \ config \ EraWebServerConfig .
   

   No related posts.