1С 8.3 : Опыт восстановления файловой базы 1Cv8.1CD

Именно 13-го июня в первый рабочий день база и слетела. Прямо с утра. При запуске пишет: «Файл базы данных поврежден. 1cv8.1CD» и все тут. Ни в конфигуратор ни в предприятие не пускает.

Последний бэкап понятно как обычно старый, ибо при последнем обновлении 1С рабочую базу перенесли в другую папку, которая соответственно в архив не попадала.

В общем вот исходные данные:

2. убитый файл 1Сv8.1CD весом 900 МБ датой от 12.06.2012;

3. рабочий файл 1Сv8.1CD весом 900 МБ датой от 26.04.2012;

На уровне подсознания понятно что из этого что то можно получить но пока не ясно как.

ИТАК:

Еще до поиска в Сети пришла в голову мысль воспользоваться стандартной утилитой 1С CHDBFL.EXE для проверки и исправления файла базы.

Ладно, заменяем жертву эксперимента файлом из «резервного хранилища».

Теперь читаем статью по формату 1Cv8.1CD и проникаемся. Ага, теперь более-менее понятно для чего и как можно использовать программу tool_1CD. Запускаем 2 экземпляра:

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

Тут нам без HEX-редактора не обойтись. А сейчас что-то мало бесплатных то ((((. А у меня еще с давних темных времен припасена коллекция редакторов и дебаггеров. Уж и не помню для чего)))).

Для тех, кто внимательно прочитал статью не секрет, что блок, где хранится размещение таблиц №2 и найти его можно по смещению 0х4000:

Так же видим что смещения одинаковы в обоих файлах. Это значит, что все вообще просто:

1. идем по указанному смещению в целом файле;

2. выделяем полностью фрагмент кода с начального смещения данной таблицы до начального смещения следующей;

3. копируем с заменой в убитый файл точно на те же адреса.

4. сохраняем изменения в бывшем убитом файле.

5. проверяем tool_1CD что таблицы появились. Прога ругаться может на индексы, но они после восстановятся.

6. (по своему усмотрению) прогоняем утилитой CHDBFL.EXE (она там поругается немного, можно не обращать внимания).

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

Источник

опять «Ошибка формата потока»

Описание проблемы: при открытии базы, как в режиме Конфигуратора, так и в режиме Предприятия возникает «Ошибка потока формата» с предложением закрыть или перезапустить. Информационная база файловая, находится на локальном диске, версия платформы 8.2.18.109.

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

Подобная ситуация («Ошибка формата потока») подробно и неоднократно описана на многих ресурсах, в том числе на инфостарте, так что в первую очередь были опробованы «простые» способы решения: удаление/добавление базы из списка, перенос на другую машину, прогон chdbfl, которые ни к чему не привели, chdbfl выявляла ошибку

, при попытке исправления которой chdbfl выкидывала из базы около 100 Мб, писала что ошибок не обнаружено, но проблему не исправляла.

Попробовал следующий вариант, через «Tool1c» выгрузил конфигурацию БД и загрузил ее в пустую информационную базу, база открылась без проблем (что говорит о том что повреждения не в системных таблицах, хотя могу ошибаться), потом из испорченной базы сделал Экспорт таблиц данных и импортировал их в пустую базу в которую была загружена конфа из поврежденной базы. Так же в базу была подгружена таблица V8USERS.
После этих действий при попытке загрузить базу в режиме предприятия появляется ошибка

В конфигуратор заходит, но при попытке сделать Тестирование и исправления возникает та же ошибка (Ошибка СУБД), а при реструктуризации таблиц возникает

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

Дополнение: При открытии через tool1c базы с импортрованными таблицами данных в логах возникает сообщение «Длина таблицы не кратна длине записи», версия tool1c 0.3.0 alpha, с возможностью редактирования базы.

Источник

Некоторые особенности устройства и работы файловой базы данных «1С:Предприятия 8»

В данном разделе рассматриваются некоторые особенности внутреннего устройства и работы механизмов файловой базы данных «1С:Предприятия 8», которые не освещены в документации, но могут быть интересны пользователям и разработчикам прикладных решений на платформе «1С:Предприятие 8». Приведенное описание соответствует платформе «1С:Предприятие» версии 8.3.4.

Устройство файла *.1CD

На самом нижнем уровне файл *.1CD или файл базы данных содержит внутри своего рода файловую систему, включающую в себя так называемые внутренние файлы. Файл *.1CD имеет страничную организацию, то есть состоит из страниц размером 4096 байт (4 К). Размер файла *.1CD всегда кратен 4 К.

Страницы адресуются их номерами. Номер страницы представлен 4-байтовым целым числом без знака. Следовательно, файл *.1CD может содержать не более чем 4 294 967 296 страниц.

Страница с номером 0 содержит служебные данные файла *.1CD, такие как версия формата файла базы данных, общее число страниц в файле и т. п.

Страница с номером 1 используется менеджером свободных страниц.

Каждая из остальных страниц может либо принадлежать какому-либо из внутренних файлов, либо находиться в списке свободных страниц.

Внутренние файлы

Страницы, относящиеся к внутреннему файлу, бывают трех видов:

Эти страницы образуют дерево, корнем которого является корневая страница, промежуточными узлами являются индексные страницы, а листьями – страницы данных.

Корневая страница содержит служебную информацию внутреннего файла, такую как длина файла, номер версии данных файла и т. п. Кроме того, на корневой странице содержится до 1018 номеров индексных страниц.

Индексные страницы образуют промежуточный уровень дерева. Индексная страница содержит число страниц данных, адресуемых данной индексной страницей, и до 1023 номеров страниц данных.

Страница данных содержит только данные.

Из сказанного выше следует, что внутренний файл может включать не более чем 1 041 414 (1018 * 1023) страниц данных. Следовательно, максимальный размер внутреннего файла не может превышать 4 265 631 744 (1018 * 1023 * 4096) байта. Для адресации отдельных байтов внутреннего файла используются 4-байтовые целые числа без знака.

Для представления внутреннего файла нулевой длины достаточно одной только корневой страницы. Если размер внутреннего файла составляет от 1 до 4096, то он представляется тремя страницами: одной корневой, одной индексной и одной страницей данных. При дальнейшем росте размера файла добавляются новые страницы данных, и их номера помещаются в индексную страницу. Как только индексная страница перестает вмещать номера страниц данных, добавляется новая индексная страница и ее номер добавляется в корневую страницу. И так далее.

Внутренние файлы не имеют имен. Для идентификации внутренних файлов используются номера их корневых страниц.

Список свободных страниц

Страницы, не относящиеся к какому-либо из внутренних файлов, находятся в списке свободных страниц. Свободные страницы могут образоваться при сокращении размера или удалении внутреннего файла. Любые освободившиеся страницы внутренних файлов помещаются в список свободных страниц.

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

Устройство базы данных

Внутренние файлы в конечном счете предназначены для хранения базы данных. База данных представляет собой совокупность таблиц. Каждой таблице может соответствовать от двух до четырех внутренних файлов:

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

Кроме того, имеется файл описания базы данных. Данный файл содержит информацию о локали базы данных, а также номера корневых страниц внутренних файлов описания для каждой из таблиц базы данных.

Таблицы

Файл описания таблицы

Файл описания таблицы содержит полное описание таблицы, которое включает:

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

Файл данных

Номера записи представлены 4-байтовыми целыми числами. Запись с номером 0 используется для служебных целей. Номера «настоящих» записей начинаются с 1.

Длина записи может быть вычислена как сумма длин всех колонок плюс от 1 до 17 байт служебной информации. Ограничений на длину записи не накладывается.

Ниже приведена информация о типах данных и соответствующем размере колонок:

Десятичное число с фиксированной точкой. Хранится в десятичном виде по две десятичные цифры на один байт. Зарезервировано место для знака. Размер может быть вычислен по формуле:

Строка переменной длины, состоящая не более чем из n однобайтовых символов. Размер колонки равен n + 2 байта. Дополнительные 2 байта используются для хранения фактической длины.

Двоичные данные переменной длины не более n байт. Размер колонки равен n + 2 байта. Дополнительные 2 байта используются для хранения фактической длины.

Значение логического типа (true или false). Размер колонки равен одному байту.

Дата без времени. Размер колонки – 4 байта.

Дата и время. Размер колонки – 7 байт.

Текст неограниченной длины, состоящий из однобайтовых символов. В структуре записи колонка занимает два 4-байтовых целых числа: фактическая длина значения и адрес в файле данных неограниченной длины. Фактические значения хранятся в файле данных неограниченной длины.

Текст Unicode неограниченной длины, состоящий из символов в кодировке UTF-16. В структуре записи колонка занимает два 4-байтовых целых числа: фактическая длина значения и адрес в файле данных неограниченной длины. Фактические значения хранятся в файле данных неограниченной длины.

Двоичные данные неограниченной длины. В структуре записи колонка занимает два 4-байтовых целых числа: фактическая длина значения и адрес в файле данных неограниченной длины. Фактические значения хранятся в файле данных неограниченной длины.

Кроме того, к размеру колонок, которые могут содержать NULL, добавляется еще один байт.

Файл индексов

В файле индексов находятся все индексы, определенные для таблицы. Детальное рассмотрение структуры индексов не входит в цели данной статьи. Отметим только, что индекс представляет собой сбалансированное дерево. С точки зрения использования файловой базы данных важным является то, что, в отличие от размера записи, на длину ключа индекса наложено ограничение: длина не может превышать 1920 байт. Ключ представляет собой конкатенацию значений всех индексируемых колонок записи плюс 4-байтовый номер записи.

Индексироваться могут колонки типов Numeric, Char, NChar, Binary, VarChar, NVarChar, VarBinary, Logical, Date и DateTime. Значение каждой из индексируемых колонок типов Numeric, Binary, VarBinary, Logical, Date и DateTime помещается в ключ как есть. Соответственно, каждая из таких колонок добавляет к длине ключа свой собственный размер. А вот для колонок типов Char, NChar, VarChar и NVarChar вместо самой строки в ключ помещается ее ключ сортировки (collation key). Поэтому вклад колонок указанных типов в длину ключа определяется как n * 3 + 2 для колонок, не чувствительных к регистру букв. И n * 4 + 3 для колонок, чувствительных к регистру.

Файл данных неограниченной длины

В файле данных неограниченной длины хранятся фактические значения колонок типов Text, NText и Image. Для хранения таких значений файл организован как набор блоков длиной 256 байт. Каждое значение хранится как односвязный список блоков. В каждом блоке содержатся:

Блок с адресом 0 используется для служебных нужд, а если точнее он содержит адрес списка свободных блоков. В список свободных блоков помещаются освободившиеся блоки, которые могут быть использованы в дальнейшем.

Работа с базой данных

Чтение данных

Следует различать чтение данных, выполняемое вне транзакции, и чтение в рамках транзакции. Операция чтения (например, SQL-запрос SELECT), выполняемая вне транзакции, получает данные, соответствующие состоянию базы данных на момент выполнения операции. При использовании SELECT вне транзакции поведение файловой базы данных подобно поведению версионных СУБД, таких как Oracle. То есть все данные, полученные запросом SELECT, относятся к одному согласованному состоянию базы данных, имевшему место на начало выполнения операции. Чтение данных не может быть заблокировано никакой другой операцией чтения или записи. Но нужно понимать, что состояние, имевшее место на начало чтения, может быть изменено. Соответственно, считываемые данные могут оказаться устаревшими.

Если чтение выполняется в рамках транзакции, то гарантируется, что считанные данные не могут быть изменены никем другим до завершения транзакции. Для обеспечения этой неизменности используется механизм транзакционных блокировок. При первом обращении к таблице на чтение в рамках транзакции на таблицу накладывается Read-блокировка. И эта блокировка не снимается до завершения транзакции.

Запись данных

Запись данных всегда предполагает наличие транзакции. Если операция записи была вызвана вне объемлющей транзакции, то транзакция будет создана неявно в процессе выполнения операции. При выполнении операции записи на таблицы, в которые вносятся изменения, накладывается транзакционная Write-блокировка, препятствующая чтению или записи, выполняемой другими соединениями.

Если на таблицу уже была наложена Read-блокировка, то выполняется ее эскалация до Write-блокировки.

Операции записи данных, выполняемые в рамках транзакции, не приводят к немедленной записи изменений в файл *.1CD. Изменения, вызванные операциями записи, накапливаются в кеше модифицированных страниц и сбрасываются в файл базы данных при фиксации (commit) транзакции.

Таким образом, если в процессе выполнения транзакции, до ее фиксации, произойдет сбой и/или падение приложения, то все изменения, произведенные в транзакции, окажутся потерянными и файл базы данных останется в неизмененном состоянии.

Кеширование данных

Кеш считанных страниц

Для повышения эффективности операций чтения механизмы файловой базы данных стараются кешировать считанные данные и тем самым минимизировать число физических операций чтения из файла базы данных. Кеш считанных страниц содержит прочитанные страницы данных внутренних файлов. Общий размер кеша для каждого из соединений с файловой базой данных является ограниченным и может в зависимости от различных условий составлять от 2 до 200 Мбайт. Кеш наибольшего размера создается при работе с файлом базы данных, расположенным на сетевом диске.

Кеш организован по принципу LRU. То есть страницы, к которым дольше всего не было обращений, могут быть вытеснены из кеша вновь считанными страницами.

Другой причиной, по которой страницы могут быть исключены из кеша, является его обновление. Каждое зафиксированное состояние данных внутреннего файла имеет соответствующий номер версии. Все кешируемые страницы внутреннего файла соответствуют определенной версии внутреннего файла. Процесс обновления состоит в том, что из файла базы данных считывается текущая версия внутреннего файла и сравнивается с версией кешируемых страниц. Если выясняется, что версия кешируемых страниц устарела, то страницы соответствующего внутреннего файла исключаются из кеша.

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

В рамках транзакции обновление кеша производится непосредственно после наложения на таблицу Read-блокировки. В дальнейшем до завершения транзакции кеш остается актуальным, так как таблица не может быть модифицирована другими транзакциями. Соответственно, для последующих операций чтения в той же транзакции обновления кеша не требуется.

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

Еще одной причиной для исключения страницы из кеша считанных страниц является попадание страницы в кеш модифицированных страниц.

Модификация данных и кеш модифицированных страниц

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

Страница, попавшая в кеш модифицированных страниц, исключается из кеша считанных страниц.

При запросе на чтение данных из внутреннего файла соответствующая страница сначала ищется в кеше модифицированных страниц. Если не найдена, то производится поиск в кеше считанных страниц. И если не найдена там, то производится считывание страницы из файла с помещением в кеш считанных страниц.

Сброс кеша модифицированных страниц в файл производится только при выполнении фиксации (commit) транзакции. При фиксации транзакции все измененные страницы всех внутренних файлов собираются в общий массив, упорядоченный по номерам страниц в файле базы данных, и запись в файл базы данных производится от больших номеров страниц к меньшим. Это делается из следующих соображений:

Время жизни кеша модифицированных страниц ограничено временем выполнения транзакции. После завершения транзакции кеш полностью освобождается.

На размер кеша модифицированных страниц не накладывается никаких ограничений. Единственным ограничителем является размер свободной оперативной памяти.

Блокировки

Транзакционные блокировки

Этот вид блокировок уже упоминался выше. Транзакционные блокировки предназначены главным образом для обеспечения логической целостности и изоляции транзакций. Транзакционные блокировки бывают двух видов:

Read-блокировки не конфликтуют между собой, но конфликтуют с Write-блокировками. Write-блокировки конфликтуют с любыми блокировками: Read и Write. Единицей блокировки является таблица. Единица довольно крупная, особенно с учетом того, что в большинстве современных СУБД поддерживаются блокировки на уровне записи. Однако реализация блокировки на уровне записи потребовала бы большого числа файловых блокировок, что привело бы к существенному снижению производительности.

Транзакционные блокировки накладываются с ожиданием. По умолчанию время ожидания транзакционной блокировки равно 20 сек.

Блокировки фиксации состояния

Также имеется ряд блокировок фиксации состояния. Данный вид блокировок относится к системным блокировкам и предназначен для обеспечения согласованного доступа к файлу базы данных на физическом уровне. При использовании файловой базы данных крайне редко приходится сталкиваться с какими-либо внешними проявлениями, связанными с этим видом блокировок. В данной статье они упоминаются главным образом для полноты картины.

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

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

Данный вид блокировок накладывается на очень непродолжительное время. Время ожидания захвата блокировки составляет 120 сек. Такое время ожидания выбрано из расчета, чтобы любая операция, прикрытая блокировкой фиксации состояния, успела завершиться. Исключительные ситуации с сообщениями «Не удалось зафиксировать таблицу для записи» или «Не удалось зафиксировать таблицу для чтения» крайне редки и возникают в основном в условиях сильной загрузки сети или компьютера, выполняющего функции файл-сервера.

Источник

Длина файла базы не кратна длине блока 0х1000 что делать

Перед тем как начать исправлять базу обязательно сделайте резервную копию!

1. Через конфигуратор

Выбрать «тестирование и исправление» и запустить.

2. Утилита chdbfl.exe

Если в конфигуратор войти нет возможности можно воспользоваться утилитой chdbfl.exe. Ее скачивать не нужно, она находится в папке, где установлена 1С.

У меня утилита chdbfl.exe находится тут

Нужно ее запустить, выбрать файл 1Cv8.1CD в папке базы 1с, поставить галочку «Исправлять обнаруженные ошибки» и запустить.

3. Очистить кэш (более подробно смотреть тут) .

Бывают такие глюки\сбои которые очень хорошо исправляются очисткой кэша.

Например один пользователь входит в базу 1с и работает без проблем, а другой или войти не может или при входе у него куча ошибок и т.п.

Способ очень простой.

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

И сделать так:

1 Выбрать в списке нужную базу

2 Удалить ее из списка, сама база не удалится. Главное запомните или запишите где она лежит.

3 Заново ее пропишите.

Сейчас у одного из моих клиентов ситуация в которой не помог ни один из этих способов.

Клиент новый, поэтому я еще не до конца разобрался как у него все устроено.

База файловая, находится на вирт машине, 1с без сервера запускается с другой вирт. машины.

Возможно 1с просто не хватает ресурсов.

Базу скачал себе, запущу и попробую поработать в ней, если ошибка не появится, то проблема точно не в 1с, а в системном администрировании.

Тогда буду перенастраивать.

Узнал что ресурсов на компьютере клиента достаточно.

Решено. Проблема была в платформе.

Переустановка платформы и удаление старых версий полностью решило проблему. 🙂

Источник

Превышен максимально допустимый размер внутреннего файла 1Cv8.1CD

Максимальный размер файловой информационной базы системы 1С:Предприятие

В настоящее время программные продукты системы «1С:Предприятие» успешно используются более чем в 1 500 000 организаций для автоматизации различных аспектов учета и документооборота. Благодаря своей универсальности и масштабируемости программы системы «1С:Предприятие» применяются как в небольших предприятиях и ИП с одним рабочим местом, так в огромных холдингах и корпорациях с тысячами рабочих мест.

Файл 1Cv8.1CD имеет страничную организацию, то есть состоит из страниц размером 4096 байт (4 К). Размер файла 1Cv8.1CD всегда кратен 4 К. Страницы адресуются их номерами. Номер страницы представлен 4-байтовым целым числом без знака. Следовательно, файл 1Cv8.1CD может содержать не более чем 4 294 967 296 страниц.

Страницы, относящиеся к внутреннему файлу, бывают трех видов:

Корневая страница содержит служебную информацию внутреннего файла, такую как длина файла, номер версии данных файла и т. п. Кроме того, на корневой странице содержится до 1018 номеров индексных страниц.

Индексные страницы образуют промежуточный уровень дерева. Индексная страница содержит число страниц данных, адресуемых данной индексной страницей, и до 1023 номеров страниц данных.

Таким образом внутренний файл может включать не более чем 1 041 414 (1018 * 1023) страниц данных. Следовательно, максимальный размер любого внутреннего файла не может превышать 4 265 631 744 (1018 * 1023 * 4096) байта

Варианты решения проблемы

Важно!
Данный вариант решения предназначен только для подготовленных специалистов! Все изменения размера внутренних страниц информационной базы вы выполняете на свой страх и риск. Мы не несем никакой ответственности за любые возможные последствия!

Важно!
Чтобы избежать риска потери данных, перед выполнением операции конвертации файлов обязательно сделайте резервную копию базы данных!

Для преобразования формата файловой базы данных в поставку платформы «1С:Предприятие» входит утилита CNVDBFL.EXE, которая должна находиться в каталоге «\bin» платформы «1С:Предприятие». Например, полный путь к папке, где находится утилита, может быть «C:\Program Files (x86)\1cv8\8.3.XX.YYYY\bin», где «8.3.XX.YYYY» – номер версии установленной платформы «1С:Предприятие».

Подробно про использование утилиты CNVDBFL.EXE можно почитать в документации по администрированию «1С:Предприятие», или на сайте ИТС: » Утилита преобразования cnvdbfl «.

Для конвертации файловой базы данных Вы можете использовать следующую команду:

Рекомендации

Если данная статья была для Вас полезной, то Вы можете поддержать авторов нашего сайта, оставив свой отзыв. Если у Вас установлен Яндекс.Браузер, то в правом верхнем углу браузера нажмите на кнопку отзывов.

размер файла 1c, размер файла 1с, максимальный размер файла 1с, превышен размер файла 1с, превышен максимальный размер файла 1с, превышен размер внутреннего файла 1с, 1с превышен максимальный размер внутреннего файла, 1с размер файла превышает максимально допустимый, превышен максимально допустимый размер внутреннего файла 1с, размер файла базы 1с, максимальный размер файла 1с 8.3

Источник