Отчёт по регистру стал вылетать с сообщением "Прекращена работа 1C:V7 starter program (multi-user)"

Если формировать отчёт за небольшой период, то работает. Если ставить чуть больше года, вылетает.

Файл регистра в базе самый большой 536Мб.

Кроме обрезания базы и перехода на SQL какие ещё есть решения?

DEP отключил, базу сжимал.

Kernel3x может помочь? Где его можно скачать?

Не ставьте год.
Измените алгоритм отчёта.
Измените структуру регистра.

(0) мониторь сколько жрет памяти во время работы отчета. ХЗ как там у тебя написано.
1Ска вылетает если сжирает, например, для ТЗ больше гига.

кстати, интересное сообщение "большой файл регистра..." никогда такого е встречал, будет возможность - приложи скрин
.
попытайся также переписать запрос, избавившись по возможности от условий типа "Когда", выкинь из запроса неиспользуемые в запросе переменные.

536 мб мало должно нормально работать. А сколько записей. может ты в ограничение по количеству записей уперся хотя ошибка выскакивала при попытке провести по этому регистру что либо. В монопольном режиме также себя ведет?

(4) может он запросто две таблицы перемножил и получил оверсайз

(4) записей 3,3 млн.
монопольно так же

(3) скрин чего?

Всем спасибо!
Только не смейтесь - нужно было сделать тестирование и исправление. :)
У заказчика спросил, он мне сказал, что делал. Вывод стар как мир: делай всё сам.

(4) ты сначала в ограничения на размер dbf файла упрешься, а уж потом, лет через 10, и в ограничения количества записей

Настоятельно рекомендовал бы для dbf-ных клиентов включать "Автоматически реиндексировать базу при необходимости (DBF)". Потому что сколько по рукам не бей, найдутся умники, которые будут отказываться от переиндексации. И это прокатывает в 19 случаях из 20. А вот на 20й - возможны последствия.

(10) "Автоматически реиндексировать базу при необходимости (DBF)"

Хм... Это где такое включается?

(11) Патчем это включается. Не очень легально.

(11) Лучше задать этот вопрос форуму через Яндекс или Гугл.
(12) Даже не буду спорить. Если у ТС есть lpt-порт, и в нем ключ (или несколько друг на друге, как у меня)... Если ТС не заботит "100% загрузки процессора" и "долгое сохранение в Excel"... Если нет надобности ни в kernel33 ни в kernel37... Если "обновление сплэш-заставки" не такое уж и медленное.. Тогда можно просто порекомендовать, если режим работы с базой позволяет, еженочно сбрасывать все сеансы, и запускать переиндексацию через пакетное "тестирование и исправление". А если время/сервер/база позволяет - то можно запускать тестирование со всеми пересчетами и проверками, раз база dbf.
Хотя по мне патч патчу рознь. Обход защиты - категорически не приемлю. Но вот править в исходной поставке *.spl, *.tip, IMAGECOL.BMP, Slice.bmp, OrdNoChk.prm, NETHASP.INI вроде как можно, а какую-нибудь seven.dll нельзя? И вообще что мне делать в январе 2038 года, ведь придётся же немножко поковыряться в 1cv7.exe, как ни крути.

(9) С регистрами возможно но тоже есть варианты. В 1 месте у меня 1sconst периодически упирается в максимально количество записей, а по размеру больше 80% не становился.

(13) в 38ом или 1с сдохнет, или я. Или вообще...