ODBC и AX3

[Alexandr A. Osipkin]

Здравствуйте.
Вот такая проблема:
Если в конфигурации АОСа указываю настройки БД: сервер, базу, имя, пароль в логах появляется такая ошибка:

Object Server [Имя сервера]: SQL diagnostics: Использовать обнаруженный протокол SQL "s" не рекомендуется в многозадачном режиме Microsoft Axapta.

+ При выполнении операции в Аксапте (перекомпиляция модуля) загрузка процессора подскачила на 100% и больше не один пользователь не мог подключится к Аксапте, в логе следующие ошибки:

Object Server [Имя сервера]: MaxMemPercentage (50) has been reached. No more connection will be accepted. Current virtual memory usuage: 1100009472


Если настраиваю ODBC и в настройках АОСа указываю ODBC. Проблема вроде как исчезла.
Подскажите пожалуйста, с чем это может быть связано.
После установки KR2 процессор АОСа стал нагружаться на 100% (работает 1 пользователь). До установки нагрузка была ниже.


AX3 SP3 KR2, SQL 2005 SP2 (база 90), На SQL и АОСе Windows 2003 SP2.

---------------------

Похоже первая и вторая проблемы не связаны между собой Еще не успел полностью разобраться

[KiselevSA]

Удалите протокол Named Pipes из используемых в настройках сервера SQL (Properties -> General -> Network Configuration...)

[fedka]

У нас все то же самое. Только 2000 sql и без KR.
В логах аоса: Object Server [Имя сервера]: SQL diagnostics: Использовать обнаруженный протокол SQL "s" не рекомендуется в многозадачном режиме Microsoft Axapta.

Пробовал все, что советовали на форуме(ах). :))

[Alexandr A. Osipkin]

Цитата:

Сообщение от fedka

У нас все то же самое. Только 2000 sql и без KR.
В логах аоса: Object Server [Имя сервера]: SQL diagnostics: Использовать обнаруженный протокол SQL "s" не рекомендуется в многозадачном режиме Microsoft Axapta.

Пробовал все, что советовали на форуме(ах). )

Проблему так и не решили??

[fedka]

Проблема ли это? У нас, как я уже говорил sql 2000 и аксапта без KR, загрузок под 100% таких нет.
Object Server [Имя сервера]: MaxMemPercentage (50) has been reached. No more connection will be accepted. Current virtual memory usuage: 1100009472

Таких сообщений нет.
Единственное я для себя до конца и не разобрался, что же лучше использовать в настройках подключения аоса к б.д.

[Alexandr A. Osipkin]

Цитата:

Сообщение от fedka

Проблема ли это? У нас, как я уже говорил sql 2000 и аксапта без KR, загрузок под 100% таких нет.
Object Server [Имя сервера]: MaxMemPercentage (50) has been reached. No more connection will be accepted. Current virtual memory usuage: 1100009472

Таких сообщений нет.
Единственное я для себя до конца и не разобрался, что же лучше использовать в настройках подключения аоса к б.д.

Сори что не поправил тему. Эти сообщения связаны с другим, не могу понять с чем Выдимо какая то операция зацикливается, или еще что.. не успел разобраться.

[AndyD]

Этот загадочный протокол SQL "s"

В общем, автор этого сообщение имел в виду конечно же другое.
Просто, перед s пропущен знак процента. Если его поставить - то сразу же будет видно, что это - форматная строка. И при появлении сообщения в инфологе будет видно, как протокол на самом деле называется.
Для проверки настроил соединение через именованные каналы - и получил название протокола (точнее, имя файла библиотеки) "DBNMPNTW".

Для исправления такой ситуации, можно на сервере запретить все подключения, кроме TCP/IP. А можно создать псевдоним (alias) для сервера с указанием сетевой библиотеки TCP/IP

Если будете исправлять ktd-файл (А именно там находится это сообщение. Его номер #281 MSG_SQL_BAD_PROTOCOL), то не забудьте удалить kti-файл для соответствующего языка и перестартовать aos (или клиента для двухзвенки) - индексный файл пересоздастся

[Alexandr A. Osipkin]

Цитата:

Сообщение от AndyD

Для исправления такой ситуации, можно на сервере запретить все подключения, кроме TCP/IP. А можно создать псевдоним (alias) для сервера с указанием сетевой библиотеки TCP/IP

На сервере SQL 2005 доступны протоколы Shared Memory и TCP/IP. Остальные выключены. Вопросик, а зачем нужен Shared Memory?

На сервере SQL 2000 включен только TCP/IP. Событие в логе тоже имело место, до настройки ODBC.

[AndyD]

А на какой протокол ругается не смотрели?

[Alexandr A. Osipkin]

Цитата:

Сообщение от AndyD

А на какой протокол ругается не смотрели?

АОС нельзя перезапускать )) много пользователей работает )

[somebody]

Цитата:

Если в конфигурации АОСа указываю настройки БД: сервер, базу, имя, пароль в логах появляется такая ошибка:
Object Server [Имя сервера]: SQL diagnostics: Использовать обнаруженный протокол SQL "s" не рекомендуется в многозадачном режиме Microsoft Axapta.

Это не ошибка, а предупреждение. Можно просто не обращать на него внимания.

Кроме того, это может быть и глюк - предупреждение о протоколе, к-рого на самом деле нет.

Цитата:

Вопросик, а зачем нужен Shared Memory?

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

[vesna dba]

Цитата:

Сообщение от AndyD

Этот загадочный протокол SQL "s"

В общем, автор этого сообщение имел в виду конечно же другое.
Просто, перед s пропущен знак процента. Если его поставить - то сразу же будет видно, что это - форматная строка. И при появлении сообщения в инфологе будет видно, как протокол на самом деле называется.
Для проверки настроил соединение через именованные каналы - и получил название протокола (точнее, имя файла библиотеки) "DBNMPNTW".

Для исправления такой ситуации, можно на сервере запретить все подключения, кроме TCP/IP. А можно создать псевдоним (alias) для сервера с указанием сетевой библиотеки TCP/IP

Если будете исправлять ktd-файл (А именно там находится это сообщение. Его номер #281 MSG_SQL_BAD_PROTOCOL), то не забудьте удалить kti-файл для соответствующего языка и перестартовать aos (или клиента для двухзвенки) - индексный файл пересоздастся

Все верно. Исправляем AXSYSRU.KTD, удаляем AXSYSRU.KTI. Стартуем AOS, получаем - загадочный протокол SQL "s" превращается в DBNETLIB.
Убираю в настройках AOS источник данных (AX 3.0 поддерживает работу без ODBC), рестартую AOS. Наблюдаю все ту же ошибку .
Возвращаю ODBC в настройках AOS, в настройках источника ODBC в настройках клиента снимаю галку "Динамически определить порт", указываю порт 1433. Сохраняю настройки ODBC, рестартую AOS - вуаля! - нет ошибки, связанной с "загадочным" протоколом.
Удаляю источник ODBC из настроек AOS, рестартую AOS - всеравно нет ошибки!
Видимо AOS запомнил параметры последнего типа подключения.
Все результаты получены эмпирическим методом. Кто опишет это теоретически - буду признателен.

[Oleg V.Cat]

Цитата:

Сообщение от somebody

Цитата:

Вопросик, а зачем нужен Shared Memory?

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

Я бы отметил, что на тестах "непоймичегожутконавароченногоразработчиками" shared memory работал (разумеется - "все всегда на одной физической машине", связка AOS-SQL) процентов на 40 быстрее, чем TCP/IP и процентов на 20 быстрее named pipes.

P.S. Кстати, на 3-ей версии MaxMemPercentage работает или нет? А то вроде подкрутил, а AOS все равно выпал в осадок, только уже без сообщения в эвент логе... На тех же 50%.

[propeller]

Похожая ошибка. Только стоит AX 2009. Ошибка эта возникает на сервера где стоит AOS (Windows Server 2008 R2). На другом сервера стоит SQL 2008.
Источник ошибки (точнее предупреждения) - com connector. Про это предупреждение может и не узнали бы, просто периодически, довольно часто "вылетает" com connector и AX пишет что он "не зарегистрирован должным образом на сервере..", хотя ты его 10 мин назад регистрировал. Может ли эта ошибка быть связан с предупреждением в event viewer? И на сколько серьезно нужно отнестись к этому предупреждению?