Планы обмена. Скрестить ужа с ежом ... миссия выполнима =)
Небольшое исследование возможности улучшить работу планов обмена 1С средствами SQL Server: view and triggers. Результаты имеют больше теоретическое, чем практическое значение. Однако тем, кто ищет нестандартные решения, статья может понравиться =)
Комментарии
Избранное
Подписка
Сортировка:
Древо
К уже имеющимся зарегистрированным объектам плана обмена тяжело примостить чтобы попробовать.
Если правильно понимаю, происходит удаление таблиц, а потом создание новых в SQL.
При следующем обновлении конфигурации 1С, таблицы перезапишутся.
Я больше не о самом механизме, а о его практическом применении. Хотел на тестовой базе проверить.
Если правильно понимаю, происходит удаление таблиц, а потом создание новых в SQL.
При следующем обновлении конфигурации 1С, таблицы перезапишутся.
Я больше не о самом механизме, а о его практическом применении. Хотел на тестовой базе проверить.
(1) На самом деле нет никаких проблем.
Оригинальная таблица регистрации изменений 1С выглядит так:
Я её просто переименовываю, а вместо неё создаю вьюху на основании следующей ниже таблицы (все скрипты есть в скачиваемом архиве):
Как видите отличаются они только одним полем [version]. То есть данные из основной таблицы 1С можно просто скопировать в новую таблицу, по дороге заполнив поле [version]. Это сделать не сложно. Обратное превращение кареты в тыкву так же возможно.
При обновлении конфигурации 1С с таблицами вообще ничего не произойдёт. Они точно не будут удалены, так как в самом худшем варианте 1С будет делать DR OP TABLE, а там VIEW ... Будет ошибка.
Если честно, то изменять структуру справочника с последующим обновлением конфигурации я не пробовал. Думаю, что в случае со справочником, таблица регистрации изменений не будет затронута, так как, как бы мы не меняли структуру справочника, таблицу регистрации изменений интересует только первичный ключ [_IDRRef], а он всегда будет неизменен. 1С достаточно умна, чтобы это понять и не трогать свои служебные таблицы лишний раз.
С регистрами сведений и теми объектами, которые регистрируют свои изменения по составным ключам, состав которых можно изменять в конфигураторе, проблемы точно будут. Тут можно сделать следующее:
1. Скопировать текущие изменения из таблицы CHANGES в ранее переименованную таблицу регистрации изменений 1С.
2. Переименовать вьюху (в данный момент она имеет название таблицы 1С).
3. Переименовать таблицу 1С из пункта 1 в своё оригинальное имя, которое она имела до создания вместо себя вьюхи.
4. Выполнить обновление конфигурации и её реструктуризацию.
5. Накатить тюнинг-пакет на новую структуру.
Могу помочь с написанием необходимых скриптов или отвечу на дополнительные вопросы.
Оригинальная таблица регистрации изменений 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. Накатить тюнинг-пакет на новую структуру.
Могу помочь с написанием необходимых скриптов или отвечу на дополнительные вопросы.
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|