Добрый день.
Есть самописная база. Есть в ней регистр Коробки с измерениями
- Продукт (справочник, потому что может быть как материалы, так и номенклатура)
- партия (справочник. Есть реквизиты ДатаПуска, ДатаНаклейки, НомерКоробки - нужны в результатах, по ним также может быть включен отбор)
- МестоОбработки(справочник.МестаХранения)
Есть ресурсы:
- Брутто
- Нетто
- КоличествоКоробок

Сделал запрос по регистру, нач. и кон остатки и движения, с детализацией по продукту, ДатеПуска (ака ДП), ДатеНаклейки (ака ДН),НомеруКоробки (ака НК).

Все работает, НО только если формировать за старый период, когда еще  мало данных. Ну, база свернута по конец ноября 2017, на 01-09-2018 формируется нормально, на 01-10-2018 уже вылетает. И уж тем более вылетает, если делать за текущий период.
Вылетает как - выдает окно с заголовком "Microsoft Visual C++ Runtime Library" и текстом:
"Runtime error!
Program:
<Здесь пустое место, не указана сама программа почему-то>
This application has requested the Runtime to terminate it in an unusual way. Please contact the application's support team for more information.". Нажимаешь [OK], и процесс пропадает. Хвосты, правда, на сервере остаются иногда. Но у меня каталог пользователя не прописан, поэтому запускается спокойно. Удаление хвостов не помогает, вылетает все равно.

Что делать? Самый напрашивающийся вариант - свернуть базу. Но это делается небыстро (свертка возможна только по субботам и максимум 3 месяца за раз), да и сам вариант - не очень-то... Это ж что, полгода, ну - 10 месяцев максимум работы - и все, остальное сворачивай?
Возможно, поможет включение в регистре у измерений флажка "Отбор движений"?
Да. Пробовал разные варианты программы - сам релиз - 27й. Но в него добавляли разные плагины, например, romix. Так вот пробовал и чистую версию, безо всяких плагинов, только доп. библиотеки подгружаются из каталога базы, для работы с весами, сканером, принтера этикеток, ну и вот 1c++. Кстати, странная вещь - когда запускаю от имени админа 1с-ку, чтобы зарегить, например, 1с++, при попытке загрузки компоненты программа ругается:

"Ошибка при создании объекта из компоненты \\pdc\1cbase\Upak\1cpp.dll (отсутствует CLSID)
RS = СоздатьОбъект("ODBCRecordset");
{\\PDC\1CBASE\TEST_BASES\TEST5\EXTFORMS\ОТЧЕТ ПО МАТЕРИАЛАМ РХ1.ERT(307)}: Неудачная попытка создания объекта (ODBCRecordset)"

А если запускаю от имени пользователя - то все ок, компонента грузится, все работает (ну, если за старый период запускать).
Пробовал запускать на серваке (часть юзеров работает по терминалке) - симптомы те же.

(0) Видимо, в данных что-то не то. Выбирайте обороты за период и вычисляйте - может падать будет на конкретном периоде. Тогда, возможно, удастся определить виновника падения. Может ТиИ надо сделать, или пересчет итогов.

P.S. Или переходите на восьмерку.

(1) База скульная. Делал выгрузку/загрузку в другую, тоже скульную (мою, в которой работаю) - по идее, при этом ТиИ ж делается?
На восьмерку это хорошо бы, правда, не факт, что все наше оборудование будет работать на восьмерке (много старья). Но это дело ну очень отдаленного будущего в любом случае, пока торговлю на УТ перетаскиваем, все силы на это.

(2) dbcc checkdb делали?

(1) " Видимо, в данных что-то не то. Выбирайте обороты за период и вычисляйте - может падать будет на конкретном периоде." - так после 01-10-2018 - на любом периоде падает! Может, просто слишком большой объем данных получается? Но я посмотрел в процессах, памяти максимум 700 метров уходит при этом.

Да, мне как-то подкинули версию программы, которая позволяет использовать памяти больше, чем типовой exe. закинул этот exe в мою локальную сборку (там много чего накидано, в т.ч. openconf). На ней, что странно, на моем компе отработало нормально и за текущий период (памяти процесс занял примерно 1 гиг), но когда я этот exe закинул в копию рабочей папки программы (где ничего лишнего, никаких openconf) - не работает. Попробовал также скопировать мой каталог на сетевой диск и запустить в терминалке - тоже вылетело...

(3) не делал, а надо (с учетом того, что в другой скульной базе, куда скопировал базу средствами 1с - аналогичная ситуация)?

Хм... не на терминалке, а на другом компе, вариант с exe работающим с 4Г оперативки - сработал... ничего уже не понимаю... на терминалке не работает, на компе другом работает...

(5) права? квоты?

так сама выборка происходит? например, с укладкой во временную таблицу?

(6) квот на серваке нет. Права все давно проставлены...
(7) Как понять? Память процесс отжирает. На чужом компе (логин под другим пользователем) и на моем (соотв-нно, логин - мой) работает нормально. На терминалке (логинюсь под собой же) не работает, хотя запускается тот же самый exe и та же самая база.

(8) понять - сделать временную таблицу, и запрос  select...into
или  увеличивать объем выборки (например, select top 100500///), и смотреть на каком рухнет.
Ну и думать, во что уперлось

Терминалка на чем? У меня у клиентов одних с терминалки на Win 2012 1cpp периодически вылетает и не работает нормально до перезагрузки сервера. С Win 2008R2 работает более чем стабильно.

(8) ээээ... если я после выполнения запроса выгружаю его в тз и делаю ВыбратьСтроку() - это оно же? Потому как я с 1с++ работал раза 2-3 всего, и мне ваши слова ни о чем не сказали. Могу привести текст запроса - сможете его откорректировать как надо для проверки?

(10) Разные есть.
win server 2003 sp1 - подо мной исправленный exe вылетает
win server 2003 R2 sp2 - работает
win server 2003 R2 sp2 (виртуалка) - не работает
win server 2003 R2 sp2 х64 (виртуалка) - работает

(11)
«подкинули версию программы, которая позволяет использовать памяти больше, чем типовой exe.»(с)
Используется больше памяти только если этот EXE запускать на х64 архитектуре.

(11) Конечно же нет. Через "Выгрузить в тз" - ты данный из Скуля вытаскиваешь в память процесса 1С-ки, потом через "Выбрать строку" ты содержимое показываешь на экран. Тебе же советуют сделать запрос вида "SELECT что-то там твое INTO #tmp FROM здесь твое остальное" (т.е. просто добавить в твой SELECT текст " INTO #tmp " перед FROM). При этом данные все останутся на стороне SQL-сервера, он сам там у себя внутри их просто перетасовывать будет. Если этот запрос выполнится без проблем, значит проблема не в данных и не в SQL, а в трансляции твоего запроса в 1С-ное представление. И тут уже надо будет смотреть - что именно в твоих данных не так.

З.Ы. Как вариант, сталкивался, например, с зависанием 1С-ки, когда с обменом прилетала новая структура каталогов и ранее было:
"Верхний уровень"  -> внутри  -> "Каталог А" -> внутри -> "Каталог Б", а с обменом их переставили:
"Верхний уровень" -> внутри -> "Каталог Б" -> внутри -> "Каталог А", то в какой-то момент структура становилась такой:
"Каталог А" -> внутри -> "Каталог Б" -> внутри -> "Каталог А" -> внутри -> "Каталог Б" ->... и т.д. И если в этот момент сделаешь к элементу внутри этих папок запрос Спр.Уровень() то 1С-ка зависает (что не удивительно)...

Может и у вас в данных какая-то подобная путаница.

(11)(13) более того, если данные выгрузить не типизируя (т.е. вытащить, например, иды справлчников в виде 9-символьной строки, не приводя к 1с-ному представлению, т.е. убрать их запроса типизацию [ $Справочник.***]) . и выгрузка пройдет нормально - значит, проблема в типизации.
ну а там классически "добавляя по одному", либо "убирая по одному" - найти проблемный.

(11) поправка
попробовал под другим пользователем, админом. ситуация на серваках аналогичная, поправленный exe на х64 работает, на х32 вылетает.
На локальных компах - работает (на проверенных - тоже винда х64).

(15) ну hogik же в (12) сказал...
ну и сколько у тебя в результате запроса данных-то получается?
и они точно все нужны и сразу?

(16) я потому и начал проверять с привязкой к разрядности операционки.
"ну и сколько у тебя в результате запроса данных-то получается? "
     за месяц сформировал на своем компе - 350 строк получил на выходе, если без фильтров формировать.
"и они точно все нужны и сразу?"
     Да, это один из стандартных вариантов формирования отчета. Разве что чаще будут формировать за день, но даже за день все равно на х86 не работает. А уж если я включу отображение дат отгрузки...

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

имхо путаешь мягкое с теплым
1. проблема в тексте запроса - вроде как нет, раз у тебя по другим периодам норм робит
2. проблема в типизации - тоже вряд ли так как на других периодах у тебя норм все
3. проблема в получении данных на клиента - имхо тут все проблема - смотришь как растет объем памяти в диспетчере задач - если абегает более 1.2 гб и 1с крашится - значит просто весь объем в оперативку не помещается - т.к. либо обход в цикле выборки, либо уменьшение количества колонок, усечение длинных строк, возможно детализация излишняя и пару группировок надо добавить

(18) странный отчет что может только за месяц работать - это просто временное решение

(18) Так у тебя в регистре кривые данные, не закрытые имерения и видимо милионы записей в минус и плюс в итоге дающие ноль.

(19) п.3 - объем смотрел. Странно - но вылетало у меня (до того, как сделал сброс остатков) - когда в памяти процесс занимал около 600-700 метров. 710 максимум было, кажется. Когда с ломаным exe запускал на 64-битных машинах (локальных и серваках) - при формировании максимум было 1 гиг с чем-то (повторюсь, проверял все, формируя отчет за 1 день). Т.е., по идее, даже обычный exe должен был работать. Но - вылетал.
Отчет может и не за месяц считать. Просто раньше он не мог посчитать и за день, вылетал. А теперь даже за месяц считает нормально, всего за 1.5 минуты))) а за бОльший период им и не надо обычно - но посчитать он теперь может.

(20) - ну да, я тоже на это думаю. Т.к. остатки инвентаризировались (со "сторно все") только по одному месту хранения. А по тому, по которому отчет считает - мы только начинаем нормально работать, с контролем остатков и все такое, так что там даже никто не заморачивался до недавнего времени, какие движения делаются, не то, чтобы контролировать остатки. Когда базу сворачивали (старались максимум полгода последних держать только), старые записи сами собой удалялись, ну и можно было бы и по этому месту хранения посчитать, сейчас, когда это понадобилось. А так получилось, что сворачивали другие базы, ну эта и разрослась вот... ну и записей много оказалось. Поэтому, видимо, когда сбросил на начало года остатки по этому месту хранения - все и заработало.))