Как заставить автоматически обновляться ADOQuery ?

← →
ega23 © (2004-05-21 11:09) [40]

Есть вариант. Делай по таймеру пинг: обновились ли записи в БД. Если обновились, то полный рефреш, раз это тебе так надо. Если нет, то дальше сидишь и дёргаешь коротенький запрос.

← →
bushmen © (2004-05-21 11:10) [41]

>А иногда у него пос..ть всемени нет

Он что, стоя на монитор смотрит? :)
А вообще-то, в этом случае, после каждой выписки очередного заказа и делай это обновление

← →
Курдль © (2004-05-21 11:11) [42]

> Rem (21.05.04 10:55) [31]
> P.P.P.S. Я бы руки поотрубал тому программеру, который бы
> заставил меня давить кнопку "Refresh" в уже открытом журнале
> всякий раз.

Разьясните мне, нафига это надо? Мне нет дела до отрывания рук программерам - это прерогатива сисадминов, на которых свалится немеряное счастье в виде меряного трафика.

Как правило в нормальных прогах есть 3 типа окон - списки, редакторы и селекторы. Список - приблизительно-информативный перечень объектов. Сомневаешься - обнови. А вот если собрался вносить что-то новое, да с выбором из других таблиц, - открывай окно-редактор и вызывай из него окна-селекторы с самыми свежими данными!

← →
Sergey13 © (2004-05-21 11:14) [43]

2Maxx221177 (21.05.04 11:05) [38]
Слушай, в зачем кладовщику/продавцу вообще журнал документов. Я бы понял еще фактическое наличие товара. А шапки документов то ему зачем?

← →
Курдль © (2004-05-21 11:15) [44]

> ega23 © (21.05.04 11:09) [40]
> Есть вариант. Делай по таймеру пинг: обновились ли записи
> в БД. Если обновились, то полный рефреш, раз это тебе так
> надо. Если нет, то дальше сидишь и дёргаешь коротенький
> запрос.

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

← →
ega23 © (2004-05-21 11:30) [45]

Здесь нужен подход именно с блокировками.

Блокировки - это безусловно. Но они нужны лишь в том случае, когда ты начал что-то оформлять. Насколько я понял автора, он хочет, чтобы в перерывах между заказами шло обновление выборки по факту изменения данных в БД. Вот на этот случай поможет пинг.

← →
Sergey13 © (2004-05-21 11:37) [46]

>Здесь нужен подход именно с блокировками.
Как раз тут блокировки совсем не нужны. Если два юзера начнут выписывать один товар (что вполне реально), один обломится. А зачем если на складе 1000 чайников и кажду продает по десятку? Нужно простое ограничение на количество>=0 и реакция в проге на возможный облом по этому пункту. И все.

← →
Курдль © (2004-05-21 11:46) [47]

> А зачем если на складе 1000 чайников и кажду продает по
> десятку?

А еслим обоим привалило счастье и к ним приперлись оптовые_покупатели_1000_чайников? Оба откроют окна выбора чайников и оба кликнут "1000/Ок!" После этого оптовые_покупатели_1000_чайников вынут чемоданы с черным налом, будут долго слюнявить бумажки, пересчитывая и через полчаса выясницца, что один оптовый_покупатель_1000_чайников обломится? А если у него нервы не выдержат?

← →
Sergey13 © (2004-05-21 11:49) [48]

2Курдль © (21.05.04 11:46) [47]
Читай внимательно "и реакция в проге на возможный облом по этому пункту".
Кстати, если такая ситуация возникает часто, то я бы уволил чела, отвечающего за закупку товара на этот склад. 8-)

← →
Rem (2004-05-21 12:18) [49]

Про чайники [47]:

На кой блокировать запись о чайниках на все время выписки накладной? Типа, я продаю чайники, а все остальные отдыхают?

Списывание оных со склада надо проводить по факту записи накладной в БД:
- Открыли транзакцию.
- Списали чайники.
- Записали накладную.
- Закрыли транзакцию.
В случае возникновения проблем - откатили транзакцию: "Не хватает чайников". Длительность транзакции - доли секунды. На такую транзакцию не то, что одну запись блокировать можно, а всю БД (мало ли!). Никто этого все равно не заметит.

Список - приблизительно-информативный перечень объектов. Сомневаешься - обнови.

Зачем обновлять весь список вручную, если он может обновляться по отдельным записям, да еще и автоматически?
И про какой траффик идет речь, раз запрашивается одна запись (измененная или новая), а не весь DataSet? В нормализованной БД одна запись (для накладной) будет "весить" не более 100-300 байт. Или Вы работаете по диалапу?

> Rem (21.05.04 12:18) [49]
> Про чайники [47]:

Круто! А хто спорит? Особенно про В случае возникновения проблем - откатили транзакцию? Тут весь сыр-бор о том, чтобы предотвратить такие инцеденты!

> Зачем обновлять весь список вручную, если он может обновляться
> по отдельным записям, да еще и автоматически?

А вот это и есть квинтессенция всей ветки! Направьте автора на путь истинный (и нас заодно) и будет нам счастье!

>весь сыр-бор о том, чтобы предотвратить такие инцеденты!

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

> И что, остальные менеджеры будут ждать?

Какое-то время - да. Но не с момента начала ввода накладной до момента ее утверждения.
Например: открываешь окно "выбрать наименование" - все блокируются. Выбрал - разблокировались. Открываешь его снова (уже с измененными тобой и другими данными) и снова выбираешь.
И так 500 раз! :)

>открываешь окно "выбрать наименование" - все блокируются. Выбрал - разблокировались.

А представь, что в этот момент комп менеджера вырубается, а накладная еще не заведена - и ... в базе благополучно пропадают 1000 чайников, хотя физически они остались на складе!

Как заставить автоматически обновляться ADOQuery ? Найти похожие ветки