Ресурсоемкая задача.

← →
Misha Uskov © (2004-08-26 13:16) [0]

Задача: максимально быстро показывать грид с содержимым тяжелого запроса (форма подбора в справочнике с остатками и резервами). Необходимо при открытии грида и при его прокрутке обновлять остатки во всех видимых записях, а также пересчитывать остаток при получении записью фокуса.

← →
Misha Uskov © (2004-08-26 13:19) [1]

Сейчас сделано так: набор данных довольно статичен, поэтому созданы триггера на таблицу справочника, которые пишут в дополнительную таблицу ID измененных записей + время изменения (i,u,d). На клиенте используется таблица в памяти, содержимое к-й синхронизируется при открытии по алгоритму - если форма открыта впервые, то выполняется запрос целиком, в противном случае выполняется запрос только по измененым с момента последнего открытия записям. В событии OnDataChange datasource-а определяется кол-во видимых записей, выбираются их ID и делается запрос по остаткам. Главная проблема, вызванная использованием закладок, текущая запись получается всегда в центре грида. Можно ли обойти это затруднение или вообще решить поставленную задачу другим способом?

← →
Sergey13 © (2004-08-26 13:22) [2]

Господи, да за чем же таким ты следишь то в реале?

← →
s999 (2004-08-26 13:28) [3]

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

Простенький потомок ДатаСета, у которого есть метод:

procedure TMyDataSet.MyGotoBookmark(Bookmark: TBookmark);
begin
if Bookmark <> nil then
begin
CheckBrowseMode;
DoBeforeScroll;
InternalGotoBookmark(Bookmark);
Resync([rmExact]); //!!! в оригинале-([rmExact, rmCenter]);
DoAfterScroll;
end;
end;

← →
Misha Uskov © (2004-08-26 13:30) [4]

(2) За справочником ТМЦ 1С :-)

← →
Misha Uskov © (2004-08-26 13:33) [5]

(3) спасибо огромное, попробую. А ларчик просто открывался :-)

← →
Sergey13 © (2004-08-26 13:34) [6]

2 [4] Misha Uskov © (26.08.04 13:30)
И что? За время прокрутки в гриде остатки успевают измениться? И какова длина списка? И что изменится если по какой то позиции остаток будет не 100000 а 99000?

← →
Sergey13 © (2004-08-26 13:36) [7]

2[5] Misha Uskov © (26.08.04 13:33)
> спасибо огромное, попробую. А ларчик просто открывался :-)
А из ларца два молодца
И ланца-дрица-оп-ца-ца
8-)

← →
Misha Uskov © (2004-08-26 13:41) [8]

(6) Это непременное условие моего заказчика. В момент выбора позиции ТМЦ остаток должен быть "самым свежим", даже если юзер открыл подбор, а клиент забыл, что ему нужно и пять минут уточняет выбор ТМЦ по телефону. Заказчик - большая фармацевтическая фирма, возможно, что им это на самом деле необходимо.

← →
Sergey13 © (2004-08-26 15:24) [9]

2[8] Misha Uskov © (26.08.04 13:41)
Критерии "Самой свежести" спроси у заказчика. Допустим та запись которая щас видна, видна уже 3 часа - оператор ушел на "5 минут". Пришел и прочитал глазами то что видит. Сделал заказ. И что? "Вторая свежесть" получилась? Пока ты выбираешь все позиции, что становится с актуальностью уже выбранных ранее?

Глупости это, а не требование заказчика. И глупость вдвойне (уж извини) воплощать это в жизнь. Тем более если это "большая фармацевтическая фирма". Я представляю во что это выльется с их объемами и номенклатурой.
Повторю вопрос:
Что изменится если по какой то позиции остаток будет не 100000 а 99000, а для заказа надо 500 штук?

← →
Misha Uskov © (2004-08-26 15:43) [10]

(9) выбранные ранее товары резервируются, т.е. затребованное количество уже не спишут.
Я думал, что вопрос риторический... С таким подходом можно показать оператору в колонке остатки просто надпись "Расслабься, дофига еще таблеточек", не проверяя фактический остаток. Даже если закупают вагонами, остаток товара все равно иногда становится нулевым и это нужно контролировать.

← →
Sergey13 © (2004-08-26 15:51) [11]

2[10] Misha Uskov © (26.08.04 15:43)
>Даже если закупают вагонами, остаток товара все равно иногда становится нулевым и это нужно контролировать.
Для этого нужно ограничение в БД kol>=0 и чуть-чуть кода в делфи (try...except). Все.

(11) А если у меня товара 10 000 на остатке, а пришел покупатель, который хочет 40 000 купить. Какое ограничение нужно вводить? Видеть остатки при выписке накладной все равно нужно

Не знаю, как оно там в фармацевтических фирмах, но могу сказать как обстоят дела в крупных оптово/розничных магазинах, с которыми я имел дело. А делается там так:
Сначало на складе набирается, упаковывается и т.д. товар для клиента, а потом уже оформляются документы, в т.ч. забиваются накладные в программе. И никакого запрета на отрицательные остатки нет. (Предупреждения - конечно есть, и далеко не у всех есть права приходовать документы, создающие отрицательные остатки) Почему ? Да потому что в реальности бывают такие вещи как висячие партии, пересортица, излишки/недостачи, а клиент не будет ждать пока кто-то разберется почему программа не дает продать 10000 товара если эти 10000 он видит своими глазами.
Видеть остатки конечно нужно, но почему бы просто не сделать кнопку "Обновить" ? А обновлять данные при пркретке грида - имхо, излишество. И огромадные тормоза :)

> Zacho © (26.08.04 20:00) [13]
> но почему бы просто не сделать кнопку "Обновить" ?
И еще повесить таймер, и если нет действий более чем 10 сек, то в "локальный" остаток записать ???, а юзер когда глянет, сам нажмет кнопку "Обновить". Время таймера можно сократить и до 1 сек ;-)

Я, вобщем-то, совершенно не против кнопки "обновить", против заказчик. В результате всех извращений (+ запросы к MSSQL через ODBC) на открытие формы затрачивается 0,35 с. К сожалению, совет s999 не помог, теперь курсор "прилипает" к нижней стороне грида.

2[12] Misha Uskov © (26.08.04 18:48)
> А если у меня товара 10 000 на остатке, а пришел покупатель, который хочет 40 000 купить.
А если у тебя какого-то товара вообще нет и не было никогда, а пришел покупатель и хочет купить 100 тонн. Ты что - заведешь строчку и продашь?

Ресурсоемкая задача. Найти похожие ветки