Компиляция исходников на новом словаре версии 8.1.

[anna]

Информация для тех, кто выполняет собственные разработки в коммерческой версии 8.1.

С начала нового 2011 года разработки модуля Заработная плата выполняются на новом словаре БД.
У разработчиков, которые выполняют собственные разработки для списка модулей, в состав которых входит Заработная плата, может возникнуть вопрос, как лучше построить технологию доработок с учетом нового словаря.
В таких случаях не стоит компилировать исходники модуля Заработная плата на новом словаре, а исходники других модулей на старом. Это лишние хлопоты. Следует установить новый словарь и выполнять доработки на нем.
Правило следующее: интерфейсы, которые не обращаются к новым таблицам, можно компилировать, как на новом словаре, так и на старом. Не имеет значения, на каком из словарей выполняется компиляция. На работу функциональности это никак не повлияет.

Ниже я привожу мнение ведущих разработчиков Галактики по данному вопросу.
Их попросили ответить на одни и те же вопросы.
"Интересует Ваше мнение по следующим вопросам.
Дано.
1.Имеется словарь базы данных.
2.В словарь добавлено несколько новых таблиц и проведена докомпиляция таким образом что контрольная сумма словаря не изменилась.
3.Имеется интерфейс, который НЕ обращается к новым таблицам.
Вопрос 1.
Можно ли скомпилировать данный интерфейс на новом словаре и работать с ним на базе данных, имеющей старый словарь.
Вопрос 2.
Известны ли тебе какие либо проблемы, которые могут возникнуть при работе по схеме предыдущего вопроса. "
Ответы.

Терсин Федор
начальник отдела системных проектов У5 (Москва)

"да, по идее всё будет работать нормально"

Виталий Корзюк,
начальник группы "Системные проекты" отдела разработки "Прикладные сервисы"

"Если кратко: все «другие» смогут работать и на старой базе.
1. По логике – да, можно скомпилировать на новом словаре и запускать на старом словаре. Но работоспособность сборки всё равно обязательно проконтролировать.
2. Обязательно возникнут очевидные проблемы – вряд ли интерфейс настолько изолирован, что не вызывает других интерфейсов (до любого уровня вложенности), которые уже не смогут работать на старом словаре. Тут скорее, одна проблема: как убедиться в том, что рассматриваемый интерфейс действительно «словарно нейтрален», т.е., в достаточной степени изолирован от данных изменений словаря. "

Ларин Михаил
ведущий инженер-программист отдела разработки "Прикладные сервисы"

"В текущей версии Атлантиса есть возможность делать create table, без оператора alter dictionary и параметра FullSQL. Подробно об этом Терсин Федор писал на форуме http://forum.galaktika.ru/viewtopic.php?p=3045#p3045 и рассказывал на семинарах. При этом контрольная сумма не будет испорчена.

Ответ на вопрос 1:
- Думаю что, если интерфейс не содержит обращения к добавленным таблицам, компиляция его на старом и на новом словаре будет давать идентичный результат. Компилировать можно как на новом так и на старом словаре. Работать это будет как на новом так и на старом словаре.
Ответ на вопрос 2:
- Если в интерфейс все же прочится ссылка на добавленную таблицу (по не внимательности, или неявно через VPP). Тестировать скорее всего его будут на новом словаре. Никто у нас не сможет обнаружить этого дефекта. Проблема вылезет у пользователя у которого остался старый словарь. Нужно принять какие то меры, чтобы автоматически заблокировать вызов новых кодов для новых таблиц, при подключении Галактики к необновленной БД.

Дудорев Александр
руководитель группы разработки модуля "Спецификации продуктов".
Отдел разработки "Производственный контур"

"Вопрос 1.
Можно ли скомпилировать данный интерфейс на новом словаре и работать с ним на базе данных, имеющей старый словарь.

Да, можно.

Вопрос 2.
Известны ли тебе какие либо проблемы, которые могут возникнуть при работе по схеме предыдущего вопроса.

Каких-либо проблем в данном случае не проявлялось."

Василевская Анна
руководитель проекта "Заработная плата",
заместитель начальника отдела разработки
ПО "Управление персоналом"

От себя добавлю совет, каким образом можно автоматически заблокировать вызов новых кодов для новых таблиц, при подключении Галактики к необновленной БД
Для этого зарегистрирована функция Exist_Table(..).
Пример.
в cminit можно проверить наличие нового словаря следующим образом :
if (not Is_Exist_Table(coArchRates))
{ Abort; Exit; }
Следуют иметь в виду, что если Вы используете новые таблицы в подцепках раздела where,
рантайма все равно не удается избежать.
В этом случае нужно использовать функцию Exist_Table(..) при вызове данного интерфейса.
В этом случае функция вызывается с параметром 0, т.е. Exist_Table(0).

[masygreen]

"да, по идее всё будет работать нормально"

вообще .. смена словаря обычно сопровождается выпуском новой версии Галки ... хз чего бы не приурочить было ??

[anna]

Сейчас планируется выпуск новой версии 9.1.
Но подождать мы не могли, изменилось законодательство РФ с 2011 года в части расчета больничных листов и законодательство Украины (введен единый социальный взнос)
В РБ и Казахстане также есть запросы по законодательству, которые ждут докомпиляции словаря уже три года.
Вообще докомпиляция словаря штука совсем не страшная. И на Атлантисе легко и быстро выполнимая. Конечно, если грамотно подойти к доработке словаря. И программировать код, чтобы он не требовал конвертации БД.
Сейчас многие системы позволяют это делать безболезненно. В AXAPTA это давно не проблема. Я слышала что в 1С словарь коплилится данамически.
Почему мы должны плестись в хвосте и ждать новой версии?
Хотелось бы наоборот. :)

[masygreen]

Сейчас планируется выпуск новой версии 9.1.
Но подождать мы не могли, изменилось законодательство РФ с 2011 года в части расчета больничных листов и законодательство Украины (введен единый социальный взнос)
В РБ и Казахстане также есть запросы по законодательству, которые ждут докомпиляции словаря уже три года.
Вообще докомпиляция словаря штука совсем не страшная. И на Атлантисе легко и быстро выполнимая. Конечно, если грамотно подойти к доработке словаря. И программировать код, чтобы он не требовал конвертации БД.
Сейчас многие системы позволяют это делать безболезненно. В AXAPTA это давно не проблема. Я слышала что в 1С словарь коплилится данамически.
Почему мы должны плестись в хвосте и ждать новой версии?
Хотелось бы наоборот. :)

ну да в 1с вобще как таковых таблиц нет - там метаданные .. но там это реализовано с умом и удобно (правда из-за этого скорость говно)..
Для галактики не все так прозрачно , наверно надо сперва избавится от контрольной суммы, добавить визуальный конструктор как в 1с - это не сложно --- но ждем финансирования как всегда :)

[anna]

Ничего. Прогресс не стоит на месте. Главное не бояться. :)

[stix]

C изменением словаря есть проблема - если сделать alter table существующей таблицы (например, добавить новое поле), то перестанут работать public функции интерфейсов, принимающих тип type$<имя измененной таблицы> - будет ошибка времени выполнения, поскольку ожидаемый тип станет другим. Эта проблема как-нибудь будет решена?

[cruger]

Эта проблема как-нибудь будет решена?

А кто кроме вас знает об этой проблеме? Номер ПиР в студию, или хотя бы номер инцидента...