Ошибка формата потока — одна из самых неприятных и труднодиагностируемых проблем в среде «1С:Предприятие 8.3». Она сигнализирует о том, что платформа при чтении данных из базы, кэша или при передаче между сервером и клиентом встретила последовательность байтов, которую не смогла десериализовать (распознать). Особенно часто эта проблема проявляется в динамических списках (например, в справочнике Номенклатура) при прокрутке, когда система подгружает очередную порцию данных. Рассмотрим подробно, как выявить причину и победить эту ошибку.
Прежде чем приступать к активным действиям, проанализируем, почему это происходит именно при прокрутке. В управляемых формах список Номенклатура — это чаще всего объект ДинамическийСписок. Когда вы крутите колесо мыши, платформа отправляет запрос к серверу на получение следующих 20–50 строк. Ошибка возникает, если:
ХранилищеЗначения (например, битая картинка или некорректный файл).Первым делом исключим самую простую причину — мусор в кэше. Рассмотрим, как сделать это правильно, так как обычного удаления базы из списка часто недостаточно.
Сначала очистим клиентский кэш. Для этого удалим базу из списка запуска и добавим ее заново. Но более надежный способ — вручную очистить содержимое папок %AppData%\1C\1Cv8 и %LocalAppData%\1C\1Cv8. Удалите все папки с именами в виде GUID.
Затем проанализируем серверный кэш. Остановим службу 1C:Enterprise 8.3 Server Agent. Перейдем в каталог сеансовых данных (по умолчанию это C:\Program Files\1cv8\srvinfo). Там нас интересуют папки внутри рабочего сервера, где хранятся данные конкретной информационной базы. Очистка этих временных файлов часто помогает, если ошибка формата потока «преследует» всех пользователей одновременно.
Выясним, не связано ли это с программными доработками формы. Рассмотрим форму списка справочника Номенклатура в конфигураторе.
Проверим вкладку «Условное оформление». Если там настроены правила выделения строк цветом или шрифтом, попробуем их временно отключить. Особое внимание уделим полям, которые добавлены через расширения. Если правило оформления пытается обработать реквизит, который в данный момент недоступен или имеет тип Неопределено, это может вызвать сбой потока данных при отрисовке строки.
Также проанализируем запрос динамического списка. Если включен «Произвольный запрос», проверим его консолью запросов. Попробуем выполнить этот запрос с аналогичными отборами и порядком. Если в консоли запросов при прокрутке результата возникнет та же ошибка, значит проблема в самих данных в СУБД.
Если ошибка появляется при прокрутке в определенном месте, скорее всего, виновата конкретная запись номенклатуры. Попробуем вычислить её.
Применим метод «половинного деления». Установим в списке отбор по коду или наименованию так, чтобы отображалась сначала первая половина справочника, затем вторая. Если ошибка возникает в первой половине — продолжаем делить её пополам. Таким образом, за 10–15 итераций мы найдем конкретный элемент справочника. Проанализируем его реквизиты, особенно те, что хранят двоичные данные. Часто помогает простое пересохранение этого элемента или очистка его присоединенных файлов.
Поскольку в системе используется БИТ.ФИНАНС и множество расширений, рассмотрим ситуацию конфликта метаданных. Даже если вы отключили расширение, записи о его реквизитах могут оставаться в системных таблицах базы данных.
Проанализируем состояние таблиц расширений. В некоторых случаях помогает полная реструктуризация. Для этого добавим в основную конфигурацию справочника Номенклатура любой фиктивный реквизит (например, Тест_Реструктуризация с типом Число), обновим конфигурацию базы данных (F7), а затем удалим этот реквизит и снова обновимся. Это заставит платформу полностью пересобрать таблицу справочника в SQL.
Если используется MS SQL Server, выполним проверку целостности базы данных командой:
DBCC CHECKDB ('ИмяВашейБазы') WITH NO_INFOMSGS, ALL_ERRORMSGS;
Если команда выявит ошибки в индексах или страницах данных, необходимо будет провести восстановление средствами SQL.
Когда отладчик не помогает (ошибка происходит на уровне ядра платформы), на помощь приходит Технологический журнал. Рассмотрим, как его настроить для поимки исключения EXCP.
Создадим файл logcfg.xml в папке C:\Program Files\1cv8\conf (для сервера) со следующим содержанием:
<config xmlns="http://v8.1c.ru/7.4/config/logcfg">
<log location="C:\LOGS\EXT_ERROR" history="1">
<event>
<eq property="name" value="EXCP"/>
</event>
<property name="all"/>
</log>
</config>
После появления ошибки проанализируем созданные логи. В них мы ищем событие EXCP, которое происходит непосредственно перед обрывом сеанса или выводом сообщения об ошибке. ТЖ часто указывает на конкретный объект метаданных или даже на имя колонки в таблице SQL, на которой «споткнулась» система.
Разберем еще одну неочевидную причину — полнотекстовый поиск. Динамические списки часто взаимодействуют с его индексами. Если индекс поврежден, при попытке позиционирования в списке может вылетать ошибка формата потока.
Попробуем зайти в «Администрирование» — «Поддержка и обслуживание» — «Управление полнотекстовым поиском». Сначала нажмем кнопку «Очистить индекс», а затем «Обновить индекс». Это гарантирует, что данные поиска соответствуют текущему состоянию базы.
Мы рассмотрели комплекс мер по борьбе с ошибкой формата потока. Начните с самого простого — очистки всех видов кэша. Если это не помогло, переходите к диагностике данных методом деления справочника пополам. В случае, если проблема носит массовый характер и связана с доработками, используйте Технологический журнал для получения точного технического описания сбоя. Помните, что платформа версии 8.3.19.1522 имела свои специфические баги, и в ряде случаев единственным решением может стать обновление платформы до актуальных веток 8.3.21 или выше, где ошибки десериализации потоков данных в динамических списках были исправлены.