Имеется очень большой результат запроса.
Что больше жрет память? Выборка или выгрузка результата в ТЗ?
То что выгрузка в таблицу значений сильно медленнее чем выборка, знаю - последняя оптимизирована только для чтения. А вот что насчет загрузки памяти? Одинаково или что-то предпочтительнее?

Ап!

(0) Проведи эксперимент, мы тебе спасибо скажем.

монопенисуально, как по производительности, так и по памяти.

проблема будет позже, при обработки ТЗ/выборки

Ничто не мешает обрабатывать запрос кусками, поместив результат запроса во временную таблицу, задав запросу Менеджер временных таблиц и отсортировать по ключевому полю.

И потом выбирать по аналогии с формой списка, ПЕРВЫЕ 1000, где КлючеваяКолонка>ПоследнееВыбранноеЗначение.

(5) Интересный способ.

(5) Интересно) Возбму на вооружение, возможно придется делать так...

(4) а в чем проблема будет при обработке? мы ж уже выгрузили запрос в ТЗ или Выборку...

(7) И что ты с ней делать будешь?

(8) Дальше там идет по информации из полученной нами ТЗ с данными формирование в виде текста формирование запроса на языке SQL, который дальше будет выполняться через ADODB.

Есть ошибка с нехваткой памяти, где она конкретно получается, выясняю

На средних объемах данных эта обработка работает, на больших - валится с нехваткой памяти

Замер производительности поможет тебе

"select top..." - это избыточные блокировки на сервер субд.
как правило страничные (блокировки).

лучше тогда выбирать интервалы

v8: запрос в цикле


в отличии от 1с77 1с8 умеет освобождать память
и для разовых обработок можно пару гигов закачать в озу

(13) 1С делает select top и я ей больше доверяю, чем некоему МихаилМ

(13) а если режим версионировния стоит?

1. Короче как понял в случае больших запросов мне надо будет помещать результат запроса во временную таблицу, далее другим запросом в цикле читать ее кусками через select top. Но у нас же во временной таблице не будет номера строки... Что можно придумать?

2. Как память освобождать? Просто уничтожаю эту временную таблицу?

3. Нужно ли как-то память очищать в случае использования выгрузок в ТЗ и выборки? Там как-то явно указывать метод Очистить() или = Неопределено?

(16)

если у записи есть первичный ключ

то указвайте как отправную точку  его в (13) тема раскрыта.

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

(18)
не нужно . работайте с составным ключом.

(18) Справочник.Контрагенты, Документ.ПКО, и.т.д. - вполне подойдут за уникальный ключ.

(16) Если удалось выгрузить в ТЗ и падение по памяти уже в ее постобработке - можно удалять ее уже обработанные строки.

(21), да! сейчас отследил - падение по нехватке памяти происходит уже после выгрузки в ТЗ при обработке полученных из нее данных. Будем удалять обработанные строки значит)

(21) а как очищается из памяти вся таблица?

Очистить() или достаточно таблице присвоить значение = Неопределено?

+(23) Таблица значений имеется в виду

Ну и Выборка тоже интересует)

(14) Select top - это неявная сортировка всегда. Если без индексов и пр - то как сервер решит. Ресурсы-то затратятся.

Насчет явного освобождения памяти, занятой таблицей значений и выборкой можете подсказать? Как это сделать?

никак

v8: Что в памяти тебе моей...

пост 25.

(25)
главная проблема это не сортировки

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

(22) если из табл. знач. в постобработке например происходит вывод в таб. док. то может так случиться, что удаляемые обработанные строки будут освобождать памяти намного меньше чем заполняемый таб. док. ее сжирает...
сам недавно воевал с КУДиР в БП 2.0 вариант - перенес все тяжелые по памяти процедуры на 64х сервер предприятия там практически нету ограничения по памяти

(30) Не, к счастью никуда не вывожу, просто обрабатываю.