Ошибка при добавлении файла в том 1с
Итак, перед нами "мёртвая" файловая база. Задача, которая стоит перед нами на текущий момент - всесторонне обследовать базу, составить максимально полный перечень проблемных мест (ошибок). Одной из распространённых ошибок у начинающих специалистов является следующая: они либо сразу и надолго "ныряют" в содержимое файла базы в hex-редакторе, пытаясь вручную разобраться в тоннах байт, что, естественно, через некоторое время вызывает эффект отторжения, либо, попробовав один какой-нибудь инструмент, и получив неудачу, выдают заключение: "База не подлежит ремонту". Лично я считаю, что к услугам hex-редактора нужно прибегать только в исключительных случаях, либо изредка, на минутку, например, чтобы своими глазами посмотреть содержимое, находящееся по определённому смещению.
А перечень инструментов и приёмов для получения информации о проблемных местах вообще довольно широк, причём даже сама платформа 1С предоставляет, как минимум, два штатных способа. Рассмотрим их поподробнее.
1. Утилита chdbfl.exe из поставки 1С:Предприятие. Запускаем её с установленной галкой "Исправлять обнаруженные ошибки".
Сразу хочу оговориться, что на данном этапе эта утилита будет использоваться нами исключительно для диагностики, поэтому, даже если она и выдаст нам какой-то изменённый, якобы отремонтированный файл базы, мы не имеем на него каких-то видов, и просто "выкидываем". Однако, внимательно изучаем протокол работы и фиксируем перечень ошибок, найденных этой утилитой.
Например, "Поврежден заголовок файла базы данных" чаще всего означает просто некорректно записанную в нём длину файла в блоках, а не полное его разрушение (чтобы в этом убедиться, достаточно на пару секунд обратиться к hex-просмотрщику или редактору, если в начале файла сигнатура 1CDBMSV8 на месте, значит, проблема только в поле длины). "Повреждено содержимое внутреннего файла " означает, что в корневом объекте существуют "битые записи", с некорректными номерами блоков заголовков, либо с испорченными блоками заголовков. И так далее.
1С:Предприятие начинает загрузку базы с чтения содержимого системных таблиц. Системными таблицами являются:
V8USERS - таблица с данными пользователей (для баз версий 8.2 и выше)
DBSCHEMA - схема (структура) БД
_USERSWORKHISTORY - история работы пользователей
_COMMONSETTINGS, _FRMDTSETTINGS, _REPSETTINGS, _REPVARSETTINGS, _SYSTEMSETTINGS - хранилища различных настроек
а также системные таблицы-каталоги:
PARAMS - содержит файлы с параметрами БД
FILES - содержит прочие системные (служебные) файлы
CONFIG - содержит файлы конфигурации БД. Здесь же, в файлах с названиями вида GUID.GUID хранятся конфигурации поставщика (отсутствие таковых является нормальной ситуацией, означающей, что либо конфигурация полностью совпадает с типовой (не включен режим изменения), либо она снята с поддержки, либо является самописной).
CONFIGSAVE - содержит файлы основной конфигурации. Отсутствие записей в ней является нормальной ситуацией, означающей, что основная конфигурация полностью совпадает с конфигурацией БД. Стоит отметить, что здесь могут содержаться не все файлы конфигурации, а только изменённые (отличающиеся от файлов конфигурации БД).
Системные таблицы-каталоги являются, по сути, аналогами каталога в обычной файловой системе, т.е. являются хранилищем некоторого набора файлов, и имеют следующие поля:
FILENAME - имя файла
CREATION/MODIFIED - дата создания/изменения
ATTRIBUTES - атрибуты
DATASIZE - размер файла
BINARYDATA - содержимое файла (двоичные данные)
Теперь мы понимаем, что записи в ТЖ типа
22:42.0169-1,DBV8DBEng,2,process=1cv8,Trans=0,Func=selectFileName,FileName=ibparams.inf
22:42.0170-3,DBV8DBEng,1,process=1cv8,Trans=0,Func=readFile,CatName=Params,FileName=ibparams.inf
означают чтение файла "ibparams.inf" из таблицы PARAMS.
3. Открываем нашу базу при помощи утилиты Tool_1CD. Здесь мы можем просмотреть таблицы, а также их содержимое (данные записей), причём для системных таблиц (DBSCHEMA, PARAMS и т.д.) поддерживается автоматическая распаковка содержимого BLOB-полей, вплоть до показа содержимого упакованных контейнеров (в таблицах CONFIG и CONFIGSAVE). Наиболее пристальное внимание уделяем тем проблемным объектам, которые были нами найдены по результатам действий из пунктов 1 и 2, а также системным таблицам (хотя, зачастую список проблемных объектов, составленный по п. 1 и 2, ограничивается именно системными таблицами).
При просмотре перечня таблиц смотрим, есть ли таблицы с окончаниями "OG" - их наличие означает, что крах базы произошёл при ТиИ или реструктуризации (в процессе выполнения этих операций 1С создаёт новые таблицы с такими окончаниями, куда пишутся данные реструктуризованных таблиц, затем исходная таблица удаляется, а новой назначается исходное имя). Также бывает полезно сравнить перечень таблиц с содержимым старого бэкапа (при его наличии, и при условии, что конфигурация не обновлялась, иначе состав таблиц, связанных с метаданными, конечно, будет различаться), это поможет выявить отсутствующие таблицы.
При просмотре таблицы CONFIG обращаем внимание, есть ли в ней файлы с окончаниями ".new" - их наличие означает, что крах базы произошёл при обновлении конфигурации БД.
Также утилита позволяет сохранить конфигурацию БД в cf-файл, что и рекомендуется сделать. Загружаем далее эту конфигурацию из файла в пустую базу, и пробуем запустить. Если всё запустилось успешно, значит, проблема нашей базы не в конфигурации.
5. Загрузка базы в систему восстановления баз 1С restoration-base-1c8. По состоянию дел на текущий момент, в данном продукте многие функции не реализованы, а некоторые, на мой взгляд, реализованы не совсем прозрачно. Кроме того, практически вся смысловая обработка данных происходит на стороне 1С, что далеко не лучшим образом сказывается на быстродействии. Например, у меня полная загрузка файла размером 230 Мб длилась около часа, за это время я уже всесторонне обследовал базу другими инструментами, и приступил к непосредственному ремонту. Окончания же загрузки файла размером 1,5 Гб я вообще не дождался - закончилось терпение. Ещё один нюанс: поскольку система является конфигурацией для 1С, то все данные исходной базы загружаются также в базу 1С, но оказываются они в табличной части одного справочника. Следовательно, даже не принимая во внимание скорость загрузки, в случае файловой базы не получится загрузить файл с исходной базой размером более 4 Гб (из-за ограничений формата). Тем не менее, проект является свободным, с открытым кодом, доступным для изменения и доработки, поэтому не могу не упомянуть про него.
Загрузив нашу базу в систему restoration-base-1c8, мы можем иследовать список таблиц:
а также просмотреть и отредактировать данные любого блока во встроенном hex-редакторе:
Просмотр записей таблиц, к сожалению, не реализован.
На этом наш список, а также сам этап обследования заканчивается. Аккуратно фиксируем и систематизируем всю собранную информацию, которую мы будем использовать далее, в процессе "лечения". Конкретные, наиболее типичные проблемные ситуации и способы их устранения будут рассмотрены в следующих статьях.
Имеем три машины:
М1 - машина с расшаренным ресурсом
М2 - машина с сервером 1С
М3 - машина с клиентом 1С
В 1С в настройках работы с файлами указываю Хранить файлы в томах на диске. Том хочу создать в ресурсе на М1.
Вопрос первый - какой пользователь должен иметь доступ в этот ресурс? Тот, от которого на М2 сервер запущен? Или тот, который на М3 клиента запускает? Или как?
Теперь немного меняем ситуацию. На М3 к базе 1С подключаемся через внешнее соединение и пытаемся присоединять файлы.
Вопрос второй - а в этом случае какому пользователю нужен доступ в общий ресурс?
Поскольку файлы присоединить у меня не получилось, то есть ощущение, что ответы на первый и второй вопрос разные.
К сожалению, вся эта система от меня далеко, управляется не мной, т.е. нет возможности по-быстрому перепробовать все комбинации. Да и вообще, был бы рад получить теоретическое обоснование.
Заранее спасибо!
p.s. Спасибо ответившим. Я до сих пор и не сомневался, что права на ресурс нужны серверу, ну, пользователю под которым он запущен. Но вот какая проблема.
Конфигурация описана выше. Если я работаю в обычном клиенте 1С на М3 я могу добавлять файлы без проблем, т.е. том настроен правильно, он доступен, ограничений по размерам нет.
И есть у меня код, который нужно выполнять, подключаясь к этой же базе через внешнее соединение. Код присоединяет файлы к документам.
Если файлы хранить в базе, то всё работает отлично - файлы добавляются. Но если я включаю хранение файлов на диске, то при попытке присоединить файл получаю ошибку:
: Ошибка при добавлении присоединенного файла "1234567890.pdf":
Не удалось добавить файл ни в один из томов.
Список ошибок:
Ошибка при добавлении файла "1234567890.pdf"
в том "Том1" (\\М1\Тома 1С\20170922\):
"Ошибка при создании каталога "\\М1\Тома 1С\20170922\":
"Неправильный путь к файлу '\\М1'. 161(0x000000A1): Указан недопустимый путь. ".".
Вопрос первый - какой пользователь должен иметь доступ в этот ресурс?
Пользователь под которым работает сервер 1с.
Вопрос второй - а в этом случае какому пользователю нужен доступ в общий ресурс?
Тому же самому - пользователю под которым запущен сервер 1с.
Файлы хранит 1с, и работает с ними 1с.
Все пользователи работают только с сервером, и не могут работать с файлами, если им нужен доступ к файлу они просят сервер, и сервер выдает им нужный файл. Поэтому пользователям 1с права на файлы не нужны вообще.
Что это такое? Куда копать? Гугл и Миста внятного ответа на вопрос не дали. Нумерация узлов в порядке.
- Вопрос задан более трёх лет назад
- 10653 просмотра
Оценить 2 комментария
Какие версии конфигураций(полностью)? Изменения в конфигурациях были, или всё типовое?УТ 10.3.13.2, БП 2.0.22.2
Изменения были, какие именно — информацией не обладаю.
1. БП предприятия не может прочитать файл обмена той версии УТ, которая у вас есть. Почитать о совместимости версий УТ<->БП.
2. Одна из конфигураций не типовая и идет попытка прочитать/записать тот реквизит, описания которого нет в шаблоне обмена.
3. Абсурдное — неверный путь до файла обмена. Попробуйте подклчюиться через COM.
ну и вообще хотелось бы гораздо больших подробностей, а не потока сознания.
3. отметаем сразу.
А какие ещё подробности вам нужны? Исходные я все привёл. УТ 10.3, БП 2.0.
ну если УТ 10.3, БП 2.0 Вы считаете как минимум полностью указанными версиями, то назрел еще один вопрос — по какой причине отказываетесь прибегнуть к услугам грамотных специалистов? У меня встречный вопрос — что вам помешало ответить на мой вопрос про подробности нормально, без ненужных подколок? Я не телепат и не могу однозначно определить, что лично вы подразумеваете под словом «подробности». прошу прощения, иногда я очень не люблю не профессионалов.Привык к тому, что обычно при постановке таких вопросов рассказывают о точных версиях ПО. Файловые или скульные варианты баз. В какой именно последовательности был настроен обмен. Типовые правила обмена или подправленные.
Обмен запускается через обработку «монитор обмена» или напрямую из списка планов обмена (что кстати очень не хорошо). Односторонний или двухсторонний.
Неоднократно были случаи когда люди просто настраивали обмены через «операции — планы обменов». Вы, я надеюсь, не так делали?
Читали ли вы в документации к конфигурации о совместимости версий?
Тем более что если обмен первый — то он проводится еще на стадии настройки плана обмена и первая порция обмена данными — это еще даже не пакет с данными, а пакет с настройками. УТ 10.3.13.2, БП 2.0.22.2
Обе файловые.
Правила обмена были взяты из обмена между УТ и БП 1.6, правились при помощи конф. «Конвертация данных» 2.1.4.1, в частности, были отключены и помечены на удаление ПКО, приёмники которых отсутствуют в БП 2.0.
Обмен запускается через Сервис — Прочие обмены данными — Все настройки обменов данными — (выбираем элемент) — кнопка «Выполнить обмен». Соответственно, в УТ стоит галочка «Выгрузить», в БП — «Загрузить».
О совместимости версий не читал, т.к. даже не представляю, где это можно посмотреть. Поиск этой информации займёт нерациональное количество времени (да-да, я уже чувствую мощную волну праведного гнева от вас). *гневно постучал ногами в пол и злобно повращал глазами*
В таком случае ничего хорошего и не ждите. БП 2.0 и БП 1.6 в плане структуры метаданных различаются разительно.
Попробуйте поискать правила именно для Ваших версий. В противном случае ничего хорошего ждать не придется. Вопрос в следующем: что происходит при вызове метода НачатьЧтение? Он пытается распарсить весь файл данных целиком? Это первый обмен? Или ошибка возникла уже в процессе работы?
1. Выгрузка не от того образа.
2. Выгрузка была с ошибками, но вам об этом не сказали.
НачатьЧтение функция, которая парсит xml файл выгрузки, обычно первое что он проверяет это узел.
Лучше конечно посмотреть по отладчику.
1. Что значит «не от того образа»? Я собственноручно выгрузил файл из УТ, тут же его пытаюсь загрузить в БП (тестирую).Отладчик показывает вылет на строке вызова функции НачатьЧтение.
Синтакс-помощник говорит нам буквально следующее:
Передаваемый в функцию объект ЧтениеXML на этот момент имеет свойство ТипУзла = Ничего, это нормально?
С появлением режима совместимости 8.3.12, как вы знаете, появилась возможность распространять расширения из центрального узла в подчиненные вместе с обменом. Будем считать, что план обмена и конфигурация у вас поддерживает передачу расширений в узлы (подробнее по настройке вы можете посмотреть, например, тут).
Казалось бы, после этого достаточно просто добавить расширение в центральный узел, установить ему признак "Используется в РИБ", выполнить обмен и принять расширение в узле! Но реальность оказалась куда "интереснее".
Идентификаторы объектов расширений
Первая проблема, с которой вы можете столкнуться в центральном узле (при использовании типовой конфигурации) при выгрузке - это возможное отсутствие записей в справочнике "Идентификаторы объектов расширений", если в расширение вы добавили новые объекты (справочники, регистры сведений и т.д.). В этом случае можно выполнить обновление справочника процедурой:
К статье прикрепил готовую обработку с одной кнопкой, которая запускает выполнение этой процедуры:
Нарушение прав доступа, файл не обнаружен Params\DBNames.
Еще одна проблема, которая может изрядно испугать рядового пользователя. Не всегда, но возникает после подключения расширения, в котором добавлены новые объекты. Пользователи даже с полным правами не могут войти в 1С, хотя вы уверены, что на свои объекты вы дали права, либо чтение/запись производится в привилегированном режиме. И вообще, почему он ругается на таблицу, явно связанную с новым добавленным объектом? При этом утилита chdbfl проблем не обнаружила, да и ТиИ результатов не дало. И вот тут стоит вспомнить шутку о том, что
В любой непонятной ситуации - чисти кэш!
Да, это именно тот случай: чистим кэш и прощаемся с проблемой!
Ошибка получения данных в узле (файловая база)
Итак, расширение в центре подключили, сделали выгрузку: осталось получить данные в узле! Да проще простого! Запускаем обмен и видим следующую картину:
Ага, думаем, расширение пришло и 1С просит перезапустить сеанс! Но после перезапуска расширение не работает, а обмен так и не идет. Ладно, смотрим ЖР:
Как так? Сеанс всего один и именно из него мы пытаемся выполнить обмен! Как еще можно это сделать? Ок, дождемся запуска обмена по расписанию. Ничего не поменялось?! Ну тогда чистим кэш, делаем тестирование. Ошибок при тестировании никаких, кэш почистили, но обмен так и не идет! После чтения ИТС, списка изменений в релизах платформ, экспериментов выяснилось, что все дело в платформе! После перебора версий выяснилось, что ошибка точно присутствует в версиях 8.3.13.1690 и 8.3.14.1565, а на версии 8.3.13.1513 обмен проходит без проблем. При этом, если на узле используется клиент-серверный вариант работы, то ошибка не воспроизводится. Опять-таки, в ходе экспериментов выяснилось: первый обмен следует запускать кнопкой "Выполнить сценарий" в форме настройки сценариев обмена; причем обмен удивительным образом проходит даже на проблемных версиях платформы! Почему таким образом удается провести обмен - пока непонятно. Стоит отметить, что в центре можно использовать любую платформу: ошибок с обменом в центральном узле не обнаружили.
Напоследок
Как выяснилось позже, если у расширения стоит признак "Используется в РИБ", то оно попадает в файл обмена при каждой выгрузке! Да, даже если вы не вносили изменений в расширение, оно все равно будет каждый раз выгружаться в узел! Так что если у вас проблемы с интернетом на точках, то самое время заняться оптимизацией состава расширения!
Следует помнить: если вы добавили новые объекты в расширении, у вас настроен РИБ через план обмена, который поддерживает передачу расширений в узлы, то обмен у вас не заработает до тех пор, пока вы у расширения не поставите признак "Используется в РИБ"!
А если вы еще не перешли на режим совместимости 8.3.12+?
Надеюсь, данная статья поможет вам сэкономить массу времени нервов! Буду рад дополнить статью также вашими замечаниями, инструкциями и "находками" по данной теме!
Тестирование выполнялось на конфигурации 1С:Розница 2.2.11.29 и платформах 8.3.13.153, 8.3.13.1690 и 8.3.14.1565
РИБ и расширения: обновление идентификаторов метаданныхСпециальные предложения
Имеется в виду ссылочные объекты?
У меня в расширении есть добавленные объекты (формы), признак использования РИБ отключен, синхронизация выполняется. Расширения в узлах обновляю вручную.
Что касается полной передачи расширения в РИБ, это и ожидалось, там просто иного не предусмотрено, ровно как и в моём решении
Ну можно же было сделать проверку по контрольной сумме: поменялась - выгружаем. Думаю, это дело времени (5)А от куда главная база узнает контрольную сумму? Хотя конечно можно было сделать, как я предлагал в своей статье, это при выгрузке в центральную базу, добавлять хеш-сумму расширение, а от неё бы уже центральная база проверяла и узнавала, надо менять расширение или нет. Но 1Сники видимо решили по проще сделать. при выгрузке в центральную базу, добавлять хеш-сумму расширение
1С вроде сейчас так и делает. К сожалению, сейчас нет РИБ под рукой, но в XML был узел с именем "DigestExtension" или как-то так (7) Тогда странно что каждый раз выгружает. В моём кстати решении, там на сервер передается хеш сумма расширения и сервер тем самым узнает что надо передавать расширение клиенту или нет. Но вот разностная выгрузка средствами языка к сожалению не возможна. (8) да с разностной выгрузкой ладно, в большинстве случаев расширение не так много весит. Надо будет повнимательней последить за хэшем расширения в файле обмена. (9) Я как то анализировал эти хеши. Была ситуация, когда хеш расширения в центральной базе не совпадал с хешем расширения в периферийной базе. Это получилось из-за того, что некий узел конфигурации-расширения из центральной базы не передавался в периферийную. Возможно этот узел использовался в предыдущих версиях платформы, а в новой версии про него забыли и он просто лежит там как мусор. Если взять расширение из периферийной базы и загрузить в центральную, то хеши расширений начинают совпадать. Я надеялся, что после совпадения хешей расширение конфигурации перестанет каждый раз передаваться в периферийную базу, но оно всё равно передаётся. Ну хоть работает, уже хорошо. Большое вам человеческое СПАСИБО! Предлагаю сделать свой bugboard платформы 1С на инфостарте. Каждое обновление платформы как игра в рулетку или взлетит или нет( (13) зачем плодить сущности?
От этого будут быстрее ошибки исправлять?
Ставлю признак "Используется в РИБ", при попытке обмена ошибка в ЦУ:
Что с это значит?
(16) Похоже, что загрузили расширение в пользовательском режиме, но сеанс не перезапустили.(17) Загружал в конфигураторе.
для чистоты: завершил все сеансы - удалил расширение в конфигураторе - перезапустил 1С - добавил расширение в конфигураторе с признаком "Используется в РИБ" - запускаю обмен в режиме предприятия - та же ошибка.
(18) та же история 8.3.13.1690, 8.3.14.1630Работает через кнопку сценарий (19) Через сценарий обмен так же не взлетает
По крайней мере в 8.3.13.1644 . (20) Решилось удалением всех расширений в конфигураторе (установленных до обновления платформы) и добавлением их по новой. Обмен пошел сразу по кнопке Синхронизировать.
Решение подойдет в случае, если в расширениях нет собственных документов и справочников. (21)Платформа 8.3.13.1644
1. Подтверждаю, если в расширении не добавлены объекты из расширяемой конфигурации (или не добавлены новые объекты), то обмен работает по кнопке "Синхронизировать".
2. Подтверждаю, вывод статьи: если в расширении добавлены новые объекты метаданных, тогда первую синхронизацию с Узлами нужно делать по кнопке "Синхр. по сценарию", тогда расширение мигрирует в удаленную базу. После этого перезапускаем базу - чтобы принялись изменения расширения и снова жмем "Синхр. по сценарию" - в этот этап "подхватываются" уже данные. Да, если не перезапустить базу, то можно увидеть, вернее, не увидеть записи для заимственных в расширение объектов. При последующих синхронизаций, лучше синхронизировать "по сценарию", а то, вдруг обновление прилетит. Да и пользователей нужно учить, если синхронизация выполнена с ошибкой, пускай перезапускают базу и снова синхронизируются.
Как-то так.
Всё это ерунда. Пока не исправят баг с платформой счастья в РИБ не ищи. Пляски с бубном помогают каждому по своему. У нас 2 сервера для 1) 8.3.14.1565 пока танцевали с бубном каким то чудесным образом из файлов обмена пропали данные по расширениям. Если раньше есть расширение в ЦБ, то в файле выгрузки идут строки
<v8de:ConfigurationExtension>
<v8de:Id>645b2314-4ade-11e9-8d9e-708bcda98ec4</v8de:Id>
<v8de:Name>ОстаткиИЦеныВПодборе</v8de:Name>
то сейчас их нет. И обмен идёт отлично. Как так получилось но я рад до следующего обновления платформы)
2) 8.3.14.1630 Здесь не помогло не чего. Так и делаем обмен через сценарий.
P.S. пока танцевал с бубоном заметил такую вещь.
Если ЦБ 8.3.14 а ПБ 8.3.13 обмен не идёт не при каких условиях, так как в файле обмена меняются строки
<v8de:Version>216.0</v8de:Version>
<v8de:Digest1>00000000000000000000000000000000</v8de:Digest1>
<v8de:Digest2 v2="57881d97074ef04efe7be54c9c51d7d2" Extensions="0000000000000000000000000000000000000000">9d1874 89ecad40d6c652763c4f4f5ac8</v8de:Digest2>
Где то на форуме многие страдали от этой проблемы. Может кому поможет.
На сайте багборда не нашел соответствующей инфы (25) Да. У меня РИБ на 2х серверах на 8.3.14.1694 взлетел. На данный момент полёт нормальный. Уже даже обновил розницу до 2.2.12.хх
Ошибка на платформе: "8.3.13.1865"
Розница: "2.2.11.24"
Напиши, потом, как дела с этой платформой у Тебя))
Да обновление платформы исправляет ситуацию, спасибо. (30) На 8.3.14.1779 точно осталась только проблема с первоначальной загрузкой расширения (либо при загрузке обновления расширения) - для решения см. пункт "Ошибка получения данных в узле" (31) расширение передаешь из центральной базы в переферийные? (32) да. При первой передаче или при изменениях расширения в центре - в узле изменения приходится принимать через кнопку "выполнить сценарий"; потом обмен проходит без проблем (29) Обновил розницу до 2.2.12.30 версия платформы 8.3.13.1865 обмен на узле РИБ возможен только через кнопку "Выполнить сценарий" и когда в базе сидит один пользователь. Как только подключается второй пользователь сразу идет ошибка "База данных заблокирована" Помогает обновление платформы решить данную ошибку? (35) к базе подключаются два пользователя на одном компьютере (36)Платформа 8.3.14.1630, Розница 2.2.13.12, файловая периферийная - та же ерунда. Обмен работает только если вручную нажать "Выполнить сценарий". В центральной все ОК. (37) решил в правилах отключить передачу расширений в РИБ, проверил на тестах - обмен работает (38) Так да, работает без проблем. А если в расширение добавить новые объекты (регистр, справочник и т.п.), то РИБ не будет работать со снятой галкой "Используется в РИБ" у такого расширения (39) а других вариантов пока не вижу, к сожалению не всегда есть возможность сделать обмен что бы на периферийной базе работал один человек. Пока идет обмен, обычно еще и торговать надо. (39) Именно так. Если в расширении есть новые объекты или изменены имеющиеся объекты на уровне данных, то расширение придется включать в обмен, без этого на периферийной базе не будут загружаться пакеты
Читайте также: