Планы обмена. Скрестить ужа с ежом ... миссия выполнима =)

0. Дмитрий Жичкин (zhichkin) 209 09.01.17 22:45 Сейчас в теме
Небольшое исследование возможности улучшить работу планов обмена 1С средствами SQL Server: view and triggers. Результаты имеют больше теоретическое, чем практическое значение. Однако тем, кто ищет нестандартные решения, статья может понравиться =)

Перейти к публикации

Комментарии
1. Jem j (jem) 84 10.01.17 18:45 Сейчас в теме
К уже имеющимся зарегистрированным объектам плана обмена тяжело примостить чтобы попробовать.
Если правильно понимаю, происходит удаление таблиц, а потом создание новых в SQL.
При следующем обновлении конфигурации 1С, таблицы перезапишутся.
Я больше не о самом механизме, а о его практическом применении. Хотел на тестовой базе проверить.
2. Дмитрий Жичкин (zhichkin) 209 10.01.17 23:56 Сейчас в теме
(1) На самом деле нет никаких проблем.

Оригинальная таблица регистрации изменений 1С выглядит так:

CRE ATE   TABLE [_ReferenceChngR71]
(
	[_NodeTRef]  binary(4) NOT NULL,
	[_NodeRRef]  binary(16) NOT NULL,
	[_IDRRef]    binary(16) NOT NULL,
	[_MessageNo] numeric(10,0) NULL
)
...Показать Скрыть

Я её просто переименовываю, а вместо неё создаю вьюху на основании следующей ниже таблицы (все скрипты есть в скачиваемом архиве):

CRE ATE   TABLE [_ReferenceChngR71_Changes]
(
	[version] bigint NOT NULL,
	[_NodeTRef]  binary(4) NOT NULL,
	[_NodeRRef]  binary(16) NOT NULL,
	[_IDRRef] binary(16) NOT NULL,
	[_MessageNo] numeric(10,0) NULL
)
...Показать Скрыть

Как видите отличаются они только одним полем [version]. То есть данные из основной таблицы 1С можно просто скопировать в новую таблицу, по дороге заполнив поле [version]. Это сделать не сложно. Обратное превращение кареты в тыкву так же возможно.

При обновлении конфигурации 1С с таблицами вообще ничего не произойдёт. Они точно не будут удалены, так как в самом худшем варианте 1С будет делать DR OP TABLE, а там VIEW ... Будет ошибка.

Если честно, то изменять структуру справочника с последующим обновлением конфигурации я не пробовал. Думаю, что в случае со справочником, таблица регистрации изменений не будет затронута, так как, как бы мы не меняли структуру справочника, таблицу регистрации изменений интересует только первичный ключ [_IDRRef], а он всегда будет неизменен. 1С достаточно умна, чтобы это понять и не трогать свои служебные таблицы лишний раз.

С регистрами сведений и теми объектами, которые регистрируют свои изменения по составным ключам, состав которых можно изменять в конфигураторе, проблемы точно будут. Тут можно сделать следующее:
1. Скопировать текущие изменения из таблицы CHANGES в ранее переименованную таблицу регистрации изменений 1С.
2. Переименовать вьюху (в данный момент она имеет название таблицы 1С).
3. Переименовать таблицу 1С из пункта 1 в своё оригинальное имя, которое она имела до создания вместо себя вьюхи.
4. Выполнить обновление конфигурации и её реструктуризацию.
5. Накатить тюнинг-пакет на новую структуру.

Могу помочь с написанием необходимых скриптов или отвечу на дополнительные вопросы.
3. Jem j (jem) 84 11.01.17 10:50 Сейчас в теме
Спасибо за разъяснение! Попробую. 1С у не предлагали такую реализацию? ) Что-то у них в этой области совсем подвижек не наблюдается.
4. Дмитрий Жичкин (zhichkin) 209 11.01.17 11:47 Сейчас в теме
(3) Нет, не предлагал. Там умные люди работают. Знают что делают. Думаю из-за необходимости поддержания обратной совместимости планы обмена ещё долго трогать не будут.
Было бы интересно узнать о практических результатах Ваших испытаний ... Поделитесь ?
Оставьте свое сообщение