//*******************************************
Процедура Сформировать()
    
    БД = СоздатьОбъект("ODBCDatabase");
    БДЗапрос = СоздатьОбъект("ODBCRecordSet");
    БДЗапрос.УстБД(БД);

       БДЗапрос.Выполнить("IF OBJECT_ID(N'tempdb..#тест', N'U') IS NOT NULL DROP TABLE #тест");  
    БДЗапрос.УстановитьТекстовыйПараметр("ТА",НачМесяца(ПолучитьДатуТА()));
       БДЗапрос.Выполнить("
    |SELECT *
    |INTO #тест  
    |FROM $РегистрИтоги.ОстаткиТМЦ Рег (nolock)
    |WHERE Рег.Period = :ТА
       |");  
       
    Рез = БДЗапрос.ВыполнитьИнструкцию("Select count(*) from #тест").ПолучитьЗначение(1,1);
    Предупреждение("В таблице " + Рез + " строк. Далее открываем диспетчер задач и наблюдаем утечку памяти.");    
       
    СчетчикЦикла = 0;
    Для СчетчикЦикла = 1 По 1000000 Цикл
        Рез = БДЗапрос.Выполнить("DELETE FROM #тест");
        Если Рез = 0 Тогда  
            Сообщить("Я упала, хотя вы этого может быть пока ещё не увидели ;( " + БДЗапрос.ПолучитьОписаниеОшибки());    
            БДЗапрос.Закрыть();    
            БД.Закрыть();
            Возврат;
        КонецЕсли;
        Форма.Заголовок(""+СчетчикЦикла);
    КонецЦикла;    
    БДЗапрос.Закрыть();    
    БД.Закрыть();
    
КонецПроцедуры

Аналогично если вместо DELETE использовать UPDATE.

(0) "v7: 1спп" - шо за зверь?

(2) здасьте! 1c++

(3) А, а я думал конфа так называется)))

информацию принял, продолжайте наблюдения

я так и знал...

(5,6) О сколько чудных....
Без шуток, а что же делать? ;(

(7) хз.. стучаться к авторам. хотя сомнительно. что исправят...

(7)
указывать конкретную ТЗ

(9) ТЗ?

(9) это вброс?

Странно... не обращал внимания, было у меня такое, что тысячами (до миллиона не доходило) выполнялись маленькие запросики один за другим роботом (около 100 пользователей у целом), вроде все ОК было.

(12) На малых выборках похоже не проявляется.

(0) Повторил. Подтверждаю утечку. Причем в конкретном примере - не зависимо от размера выборки (13)

что в исходном виде, что вот в таком:
    |SELECT TOP 10 $Рег.Товар,$Рег.Количество
    |INTO #тест  
    |FROM $РегистрИтоги.ПартииТоваров Рег (nolock)
    |WHERE Рег.Period = :ТА
Память на клиенте отжирается процессом 1С с одинаковым приращением порядка 4 Мб/сек в первом и втором случае. На сервере с памятью - никаких изменений.

+(14) при этом если не обрывать по Esc обработку где-то на пороге до 500 Мб сожранной памяти - 1С после обрыва обработки при закрытии валится. Если меньше 500 Мб - то закрывается корректно
Естественного обвала не дождался - памяти на клиенте дюже много - досидел до 2 Гб (счетчик цикла = где-то на 300 000)

..программисты такие программисты...

На самом деле это печально..

Нет утечек. 1С++ 3.2.4.0. 1С r25, с примочкой от spock'а

для интересу, попробуйте в начало запросов вставить
Set NoCount ON
обработка сообщений от ODBC - волшебная штука, и может приводить к печальным последствиям

(18) откуда 3.2.4.0? последняя же 3.2.2.0

(18) BINGO
Set NoCount ON
Спасибо, дорогой товарищ!

(19) 3.2.4.1 даже есть
(18) "обработка сообщений от ODBC - волшебная штука" - а можно по-подробнее?
Утечка пропала, причем, если в той же сессии 1С-а, оборвав выполнение и убрав "Set NoCount ON" снова запустить - утечка не появляется

(21) потому что этот параметр уже установлен.

(21) А где ж взять то 3.2.4.х?

Каюсь. На форуме.

(18) все, разобрался

Когда вместе с результатом выполнения запроса сервер возвращает ещё и некие сообщения (типа (498 row(s)affected)), появляющиеся если не указать обратное, то в интерфейсе ODBC это как-то так передаётся, что фиг это обработаешь без бутылки. Поэтому в 1С++ сообщения не обрабатываются вообще. Но ODBC на это обижается - в данном случае пожирая память. А может и просто упасть.

Поэтому, Set NoCount ON ставится на автопилоте. И когда 1С внезапно падает от запросов, первое что делается - это текст засовывается в студию, чтобы посмотреть на мессаги.

(0) И где именно утечка? :)

(19) Вы отстали от жизни :)

(26) Как мило... тут получается уже проблема на уровне ODBC :)

ну, типа того
думаешь, зря все 1С-ные sp-шки начинаются с этого заклинания?

(30) Не знаю... чета не обращал на это внимание :)