Галактика в вопросах и ответах

Подскажите в какой последовательности надо делать докомпиляцию:
1. Сначала синхронизировать компоненты, а потом докомпиляцию.
2. Сначала докомпиляцию, а потом синхонизировать.

Да так то вроде не важно. Если MSSQL, то нужно сначала NAPSRV обновить - без этого не конектится от слова вообще.
А уж что там в components записано должно быть все равно. Могут конечно и какую то обработку сделать - типа если этот рес не подключен, то эти таблы не добавлять, но поскольку все програмеры ленивые по природе, то врядли.
Таблы по диадоку уже вроде как в стандарт включили.
вообще общий порядок такой
1. Выполняем проверку служебных объектов по необходимости в сапорте - востановление БД .... .
2. обновляем DB_INST, сапорт, галактику - именно в такой последовательности.
3. Обновляем NapSrv по потребности
проверяем работу сапорта.
4. обновляем Патчманагер
5. Выполняем проверку служебных объектов в сапорте - востановление БД .... .
6. Докомпилируем словарь
7. Пересобираем свои ресы.
Можете его всегда придерживаться и проблем будет меньше.

Все было хорошо.
На тестовой базе докомпиляция отрабатывала без ошибок.
В начале февраля обновил напсервер.
Теперь при докомпиляции дает ошибку
tTabledef.initsegment: не найдено поле.
Засада.
Хотел обновить рабочую базу (((.

Докомпилировать нужно Alter_Cumulative_exe_91170.acd
Предыдущий ломал индексы в самой субд.

edward_K писал(а):...
вообще общий порядок такой
...
6. Выполняем проверку служебных объектов по необходимости в сапорте - востановление БД .... .
...

я бы порекомендовал этот пункт выполнять ВСЕГДА ПЕРЕД и СРАЗУ ПОСЛЕ обновления атлантиса.
Перед на текущей версии, после - на обновленной.

Даже (!!!) если это не прописано в инструкции по конкретному обновлению.

Периодически полезно, хотя бы в режиме проверки без исправления, выполнять проверку триггеров и индексов.
При наличии сообщений от чеки об обнаружении ошибок консультироваться с техподдержкой "шо у меня там такое" (с)

Ибо при докомпиляции (изменении струтуры объектов в БД) могут возникать всякие "тонкие моменты" именно на тех местах где чеке что-то не понравилось - ибо докомпилятор полагает, что объекты в БД соответствуют его ожиданиям.
Если это не так - моет случиться всякое ...

Ну и конечно, тестовые докомпиляции на актуальной копии боевой БД - залог здоровья и успеха.

AlexMK писал(а): я бы порекомендовал этот пункт выполнять ВСЕГДА ПЕРЕД и СРАЗУ ПОСЛЕ обновления атлантиса.
Перед на текущей версии, после - на обновленной.
Ну и конечно, тестовые докомпиляции на актуальной копии боевой БД - залог здоровья и успеха.

Согласен. Особливо если после предыдущего обновления этого не сделали. Обновил порядок.
Мне показаолось, что важно проверку запускать по одному пункту - иногда проверка не проходила.
И начинать нужно именно с правой стороны первые два пункта(если смотреть параметры в сапорте).
Остальное долго и не всегда нужно.

Всем,привет! Помогите разобраться!
Был обновлен ехе, в том числе обновился NAP до версии 5.5.33
Поднял базу для конвертации 8 в 9, начал конвертацию и практически в самом начале вышла ошибка (скрин прилагаю). Чек по базе проблему не решает.
При повторном запуске ругается, что словарь не найден. Приходилось для проверки каждого варианта переподнимать базу .
После изысканий решили вернуть старый NAP версии 5.5.29. После некоторых проблем NAP был корректно установлен, снова поднята база и конвертация успешно прошла то место, на котором выходила ошибка.
В чем проблема?
https://cloud.mail.ru/public/7S5d/RAZV76jhQ

Судя по версии ASQL(5.5.16) он уже не совместим с новым напом.
Вариант либо попробовать подложить все из сапорта, либо поработать на старом напе.
Ну или запросить в ТП обновление конвертора.

edward_K писал(а):Судя по версии ASQL(5.5.16) он уже не совместим с новым напом.
Вариант либо попробовать подложить все из сапорта, либо поработать на старом напе.
Ну или запросить в ТП обновление конвертора.

Спасибо, будем запрашивать обновление конвертора у ТП. А пока на старом напе.

Добрый день! После докомпиляции словаря протект включаем из саппорта?
Просто получилось такая ситуация, что в саппорте не удалось включить протект (давал ошибку, и отправлял за подробностями в ms70drv, а там ничего кроме сообщения от NAP), пришлось включать скриптом
update x$journalconfig
set typejournal=1
update abonents
set protecton=1
from x$journalconfig
where abonents.officeno=x$journalconfig.officeno

Правильно ли это?

И еще, некоторые пользователи после докомпиляции не смогли зайти под своими паролями, приходилось перебивать в саппорте, из за чего это могло быть?

Chernikov писал(а):Добрый день! После докомпиляции словаря протект включаем из саппорта?
Просто получилось такая ситуация, что в саппорте не удалось включить протект (давал ошибку, и отправлял за подробностями в ms70drv, а там ничего кроме сообщения от NAP), пришлось включать скриптом
update x$journalconfig
set typejournal=1
update abonents
set protecton=1
from x$journalconfig
where abonents.officeno=x$journalconfig.officeno

Правильно ли это?

И еще, некоторые пользователи после докомпиляции не смогли зайти под своими паролями, приходилось перебивать в саппорте, из за чего это могло быть?

Включать и выключать надо родными кнопками в саппорте, а не запросами ..

Вы должны были после обновления системы сделать проверку данных.
Это в востановлении БД.
Если MSSSQL , то после установки обновлений установить новый napsrv.
Проверку делаете по очереди, ставя галки в правом столбике.
На вопрос исправление отвечаете утвердительно.
Возможно есть какие то проблемы с ролями.
Кроме того нужно смотреть Ms70Drv. При установке этого обновления, например там был совет
посмотреть журнал сервера(не базы). И там была написана проблемная роль, созданная руками.
Править таблицы руками крайне не желательно. Ну тригера сработают, но там может быть еще какая то обработка.