В процессе работы с крупными справочниками или журналами документов пользователи и разработчики часто сталкиваются с неприятной особенностью: при попытке выгрузить данные через стандартную команду «Еще — Вывести список» в итоговый табличный документ попадает ровно 2000 записей, хотя в самом списке их десятки тысяч. Прокрутка списка подтверждает наличие всех данных, но механизм вывода словно «упирается» в невидимую стену. Разберем подробно, почему это происходит и как исправить данную ситуацию.
Проанализируем техническую сторону вопроса. Данная проблема не является ошибкой программного кода конфигурации или настроек прав доступа. Это классическая ошибка платформы «1С:Предприятие 8.3». В частности, она наиболее остро проявлялась в версиях линеек 8.3.15 (например, 8.3.15.1700) и 8.3.16 (8.3.16.1063).
Суть проблемы заключается в том, как платформа взаимодействует с системой управления базами данных (СУБД) через курсоры. При использовании динамического списка данные запрашиваются не все сразу, а порциями (пакетами). В некоторых релизах платформы механизм, отвечающий за команду Вывести список, некорректно обрабатывает получение следующей порции данных после достижения лимита первой выборки (который часто равен 1000 или 2000 строк). В результате процесс чтения прерывается, и пользователь получает неполный отчет.
Интересно, что проблема часто зависит от конкретной СУБД: на Microsoft SQL Server она встречается регулярно, в то время как в файловых версиях или на PostgreSQL может не проявляться вовсе. Это подтверждает гипотезу о некорректной работе драйвера платформы с серверными курсорами.
Поскольку проблема признана разработчиками 1С как ошибка (например, зарегистрированная под номером 10214154), самым правильным и надежным решением будет обновление платформы. Рассмотрим этот процесс:
8.3.17.1386, риск столкнуться с этим багом крайне высок.Вывести список начнет корректно запрашивать все данные, имеющиеся в динамическом списке, игнорируя старое ограничение в 2000 строк.Если оперативно обновить платформу невозможно (например, из-за жестких регламентов или требований совместимости), разберем «хитрый» способ обхода через интерфейс. Этот метод использует другой внутренний алгоритм платформы для формирования коллекции данных.
Рассмотрим порядок действий для пользователя:
Как показывает практика, при выводе именно выделенных строк платформа не использует проблемный механизм инкрементального считывания курсором, а обращается к уже сформированному списку идентификаторов, что позволяет выгрузить все 50 000 и более строк без потерь.
Проанализируем ситуацию со стороны разработчика. Иногда ошибка провоцируется настройками самого объекта ДинамическийСписок в конфигураторе. Посмотрим на два ключевых свойства:
1. Динамическое считывание данных (Dynamic Data Read).
Это свойство определяет, будет ли платформа подгружать данные по мере прокрутки. Существует парадокс: в некоторых случаях отключение этой галочки заставляет платформу сразу пытаться получить больше данных, что помогает при выводе. Однако чаще эффект обратный — именно включенное свойство в сочетании с багом платформы ограничивает вывод. Попробуйте изменить это состояние в свойствах списка на форме и протестируйте результат.
2. Основная таблица (Main Table).
Если ваш динамический список построен на произвольном запросе, крайне важно, чтобы в поле ОсновнаяТаблица был выбран конкретный объект (например, Справочник.Номенклатура). Если это поле пустое, платформа строит запрос как к «простому» набору данных, что отключает многие оптимизации и может приводить к срабатыванию лимита в 2000 строк при выгрузке. Установка основной таблицы часто решает проблему.
В случаях, когда стандартная кнопка «Вывести список» категорически отказывается работать правильно, а данные пользователю нужны регулярно, мы можем реализовать собственную кнопку выгрузки. Это гарантирует результат, так как мы будем использовать объект Запрос, который не имеет подобных ограничений.
Посмотрим на пример кода, который можно разместить в обработчике команды формы:
&НаСервере
Процедура ВыгрузитьСписокВТабличныйДокументНаСервере()
ТабДок = Новый ТабличныйДокумент;
// Получаем схему компоновки данных из динамического списка
Схема = Элементы.Список.ПолучитьИсполняемуюСхемуКомпоновкиДанных();
Настройки = Элементы.Список.ПолучитьИсполняемыеНастройкиКомпоновкиДанных();
КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
МакетКомпоновки = КомпоновщикМакета.Выполнить(Схема, Настройки, , , Тип("ГенераторМакетаКомпоновкиДанныхДляКоллекцииЗначений"));
ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
ПроцессорКомпоновки.Инициализировать(МакетКомпоновки);
ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
ПроцессорВывода.УстановитьДокумент(ТабДок);
ПроцессорВывода.Вывести(ПроцессорКомпоновки);
// Помещаем результат во временное хранилище для передачи на клиент
АдресХранилища = ПоместитьВоВременноеХранилище(ТабДок, УникальныйИдентификатор);
КонецПроцедуры
Используя объект КомпоновщикМакетаКомпоновкиДанных, мы фактически повторяем логику системы по формированию данных, но полностью контролируем процесс и обходим ограничения интерфейсных курсоров. Этот метод особенно полезен, если в списке наложены сложные пользовательские отборы, которые трудно повторить простым запросом.
Подводя итог, можно сказать, что ограничение в 2000 строк — это не настройка производительности, которую можно просто изменить в SQL Server или файле conf.cfg. Это внутреннее поведение платформы определенных версий.
Краткий чек-лист для решения проблемы:
Рассмотренные методы позволяют гарантированно обойти ограничение и обеспечить пользователям доступ ко всему объему необходимой информации.