• 15 апреля стартует «Курс «SQL-injection Master» ©» от команды The Codeby

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

    На последнюю неделю приходится экзамен, где нужно будет показать свои навыки, взломав ряд уязвимых учебных сайтов, и добыть флаги. Успешно сдавшие экзамен получат сертификат.

    Запись на курс до 25 апреля. Получить промодоступ ...

нестандартный автообмен

  • Автор темы alexgri
  • Дата начала
A

alexgri

1cv77 файловая + 3 периферийных
организован автообмен
в один из дней произошел сбой и группа документов не попала с периферии в центральную базу.
дальше все восстановилось кроме не попавших в центр документов
в результате в периферийной базе документы присутствуют, в центральной нет, но в файл автообмена этот косяк не попадает.
Отсюда вопрос
Как восстановить документы в ЦБ наиболее безболезненно?
Может можно как-то подвинуть дату обмена или перепровести злосчастные документы?
В крайнем случае можно ли их как-то выгрузить из периферии и загрузить в ЦБ за определенную дату?
Я не спец по 1с, но подозреваю, что готовое решение должно быть...

P.S. Есть в наличии копия ЦБ на дату сбоя, в которой упомянутые документы присутствуют.
 
D

Darlock

Как восстановить документы в ЦБ наиболее безболезненно?

Перепровести с внесением изменений. Т.е. зайти в док. поменять дату дока на ту же самую и провести.

Может можно как-то подвинуть дату обмена или перепровести злосчастные документы?

Можно.

В крайнем случае можно ли их как-то выгрузить из периферии и загрузить в ЦБ за определенную дату?

Можно. Составить план обмена в формате XML. А за этим обратиться за помощью к сецу.
 
A

alexgri

Перепровести с внесением изменений. Т.е. зайти в док. поменять дату дока на ту же самую и провести.



Можно.



Можно. Составить план обмена в формате XML. А за этим обратиться за помощью к сецу.


Спасибки. Я так и предполагал. Нужно было мнение специалиста.
Попробую и доложу. ;)
 
V

vitfil

Перепровести с внесением изменений. Т.е. зайти в док. поменять дату дока на ту же самую и провести.
Можно. Составить план обмена в формате XML. А за этим обратиться за помощью к сецу.
Не обязательно с внесением изменений. О каком плане обмена идет речь в отношении 7.7?
 
D

Darlock

Про план обмена никто и не говорит :)

Внесение изменений в док - для чистоты эксперимента.

а составление XML-правила - стандартная процедура при переносе определенных доков или справочников в 7.7. Если не использовать МОД (менеджер обмена данными). XML + обработка "Универсальная загрузка/выгрузка ..." выгрузит в XML док. Потом XML по этому же правилу загружается в приемник и все норм.
 
V

vbs

а составление XML-правила - стандартная процедура при переносе определенных доков или справочников в 7.7. Если не использовать МОД (менеджер обмена данными). XML + обработка "Универсальная загрузка/выгрузка ..." выгрузит в XML док. Потом XML по этому же правилу загружается в приемник и все норм.
Я для этих случаев пользуюсь своей обработкой переноса документов. Тот самый случай - одинаковые конфигурации, согласованные по справочникам
(или в УРИБ не так ?)
 
V

vitfil

Господа, зачем велосипед изобретать? 1С его уже изобрела. УРБД называется. Причем, трехколесный. Причем, третье колесо открутить нельзя.
 
V

vbs

Ага, и прикручивать четвертое колесо
Если велосипед двухколесный, третье колесо ему только придаст устойчивости. А про четвертое - это уже досужая выдумка :)
Я ведь ни одного дельного предложения не видел в этой дискуссии - что же делать, когда в УРБД стандартный обмен не сработал.
 
V

vitfil

что же делать, когда в УРБД стандартный обмен не сработал.
В каждом конкретном случае свои действия. Универсального решения нет. Надо и политики миграции учитывать, и многое другое.
 
A

alexgri

Господа, спасибо за участие.
Все оказалось проще и сложнее.
Проще, потому что не пришлось ничего делать - через день обновление прошло и нужные документы появились.
Сложнее, потому что остался непонятным сам факт перекоса в синхронизации и причина, по которой он (перекос) сам себя исправил.
Хотя нет. Причина есть - имел место небольшой откат базы с потерей изменений за 1-1.5 часа работы.
Зато все произошедшее натолкнуло на мысль, как разгрузить сервер и увеличить надежность целостности БД. Но это, видимо, лучше поставить в отдельную тему...
Еще раз всем спасибо.
 
Мы в соцсетях:

Обучение наступательной кибербезопасности в игровой форме. Начать игру!