Ре-синхронизация системных таблиц на основании AOT

[kashperuk]

Сегодня интересный пост был на внутреннем форуме.
Что-то, чего мне никогда не доводилось делать, но, возможно, будет полезным кому-то еще:

Если системные таблицы в базе данных по какой-либо причине рассинхронизировались, или не создались при попытке запуске АОС, то АОС не сможет стартовать. Такое возможно, к примеру, после неудачного апгрейда.
Примерные сообщения об ошибке, которые при этом видит пользователь:

Цитата:

Object Server 05: The database reported (session 1 (-AOS-)): [Microsoft][SQL Native Client][SQL Server]Invalid object name 'SYSSERVERSESSIONS'.. The SQL statement was: "SELECT A.SERVERID,A.AOSID,A.INSTANCE_NAME,A.VERSION,A.LOGINDATETIME,A.LOGINDATETIMETZID,A.STATUS,A.LOADBALANCE,A.WORKLOAD,A.LASTUPDATEDATETIME,A.LASTUPDATEDATETIMETZID,A.RECVERSION,A.RECID FROM SYSSERVERSESSIONS A WHERE (STATUS=?)"

Object Server 05: SQL diagnostics: [Main Microsoft Dynamics Application Object Server Session]Unable to report problem. Attempted to open message 310.

Object Server 05: Dialog issued for client-less session 1: Cannot select a record in Current AOS instances (SysServerSessions). ServerId: 0, .
The SQL database has issued an error.

Object Server 05: The database reported (session 1 (-AOS-)): [Microsoft][SQL Native Client][SQL Server]Invalid object name 'SYSCLIENTSESSIONS'.. The SQL statement was: "SELECT A.SESSIONID,A.SERVERID,A.VERSION,A.LOGINDATETIME,A.LOGINDATETIMETZID,A.STATUS,A.USERID,A.SID,A.USERLANGUAGE,A.HELPLANGUAGE,A.CLIENTTYPE,A.SESSIONTYPE,A.CLIENTCOMPUTER,A.RECVERSION,A.RECID FROM SYSCLIENTSESSIONS A WHERE (SERVERID=?)"

Object Server 05: Internal Error occurred executing stored procedure when creating session for the AOS.

Эти (и другие) системные таблицы можно обновить/пересоздать, выполнив следующую SQL команду и перезапустив AOS.

update SqlSystemVariables set value = value - 1 where parm = 'systabversion'

Объяснение:
Ядро системы использует эту таблицу, а конкретно значение параметра systabversion для определения статуса синхронизации таблиц. Устанавливая значение systabversion меньшее на 1, мы "говорим" АОSу, что нужно пересоздать нужные системные таблицы.

[glibs]

Мне не охота проверять, но кажется, мне помогало

Ax32.exe -repair

[egorych]

-repair вроде работает, если версия клиента ниже чем в базе записано

[glibs]

Работает он всегда. В этом случае тоже помогает.

Правда я потом уже сообразил, что я в 3.0, видать экспериментировал.

Насколько удастся стартовать -repair для АОСа в 4.0 и 5.0 не уверен.

В общем, просто идея. Если будет повод — я проверю.

[sukhanchik]

Цитата:

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

Ядро системы использует эту таблицу, а конкретно значение параметра systabversion для определения статуса синхронизации таблиц.

Это не совсем так. В АОСе (как и в клиенте) прошит номер версии таблиц, который ожидается в БД (SQLSYSTEMVARIABLES) в этом параметре. Если в АОСе прошит номер, больший чем в БД, то аксапта считает, что производится апгрейд версии и запускает синхронизацию всех (в т.ч. системных) таблиц.
Кто переходил в 3.0 с SP3 на KR1 тот вспомнит - что так было добавлено поле RecVersion во все таблицы. Т.е. когда натравливаешь клиента KR1 на БД от SP3, то первый запуск производится долго (синхронизация все-таки) - зато потом чудесным образом появляется RecVersion

2 kashperuk
на 5-ке запускали?
у меня не пошло, хотя проблема несколько другая была. АОС не поднялся после смены версии.

[kashperuk]

Цитата:

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

2 kashperuk
на 5-ке запускали?
у меня не пошло, хотя проблема несколько другая была. АОС не поднялся после смены версии.

Нет, не проверял или это работает на 5ке.

на 5-ке -repair заработал только после удаления на SQL нескольких системных таблиц. После чего доступ к АОС с клиента стал недоступен