Очистить память после разноски журнала ОС

[npokypatop]

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

Собсно, суть проблемы. Есть куча журналов с амортизацией ОС. В журналах от 1000 до 15000 строк.
Все журналы нужно разнести (и в короткий срок, но Б-г с ним, со сроком, хотя бы разнести).
Перед разноской пользователям нужно предварительно просмотреть журнал. Им это очень нужно...
Итак, первый журнал "просматривается" нормально, отъедая порядка 500Мб за час предв.разноски журнала (на 5000 строк).
Но после завершения операции память не возвращается (даже по прошествии некоторого времени). Соответственно, следующий журнал пожирает всю доступную память, иногда АОС падает, иногда нет, но это уже неважно

А вот теперь вопрос - как? как чистить память? Операции

Global::smartHeapMemorySizeUp()
hc.shrinkPool()
hc.postCompactingMessage()

не помогают ((

версия MSSQL 2000 SP4
версия MDAC 2.82.3959.0
версия DAx kernel 4.0.2163.0
appl 4.0.2214.0

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

[MironovI]

Вот когда вспомнишь с ностальгией про двухуровневый режим

[Михаил Андреев]

ИМХО: У меня возникает ощущение, что проще разобраться с пользователями или переделать предварительный расчёт этих проводок, сделав отчёт по журналу, например. Отчёт оптимизировать всегда можно под нужды клиента, сделав нужную группировку, и счета подцепить. Тем более, журнал простой - амортизация. Это не выбытие с убытком

[npokypatop]

Цитата:

Сообщение от Михаил Андреев

ИМХО: У меня возникает ощущение, что проще разобраться с пользователями или переделать предварительный расчёт этих проводок, сделав отчёт по журналу, например. Отчёт оптимизировать всегда можно под нужды клиента, сделав нужную группировку, и счета подцепить. Тем более, журнал простой - амортизация. Это не выбытие с убытком

Эээ.. простите, а какие способы разборок с пользователями Вы можете предложить?.. И не совсем понятно насчет переделки расчета. Нужно, чтобы ОС из одного филиала были в одном журнале, и чтобы номер документа был один - это выгружается дальше в другую систему. Т.е. по-любому надо выгружать скопом, как ни извращайся.
Вариант выгрузки не во временную таблицу, а в постоянную, тоже не помогает. Единственное преимущество - то, что выгруженный журнал можно просмотреть еще раз.

[MironovI]

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

[konopello]

Цитата:

Эээ.. простите, а какие способы разборок с пользователями Вы можете предложить?.. И не совсем понятно насчет переделки расчета. Нужно, чтобы ОС из одного филиала были в одном журнале, и чтобы номер документа был один - это выгружается дальше в другую систему. Т.е. по-любому надо выгружать скопом, как ни извращайся.

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

[npokypatop]

Цитата:

Сообщение от konopello

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

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

[UNRW]

например, мы проблему решали тупо:
автоматически создаются журналы амортизации по 1000 строк (делали простенькую модификацию) т.к. с ростом кол-ва строк время разноски расет нелинейно