Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Как заставить автоматически обновляться ADOQuery ? [D7, MSSQL]

Страницы: 1 2 3 >
Maxx221177 © (2004-05-21 09:48:00)
Как заставить автоматически обновляться ADOQuery при изменении в таблицах MSSQLServer2000 из которых он тягает данные. Приложение многопользовательское и при внесении данных одним юзером, их сразу должны увидеть другие.

bushmen (2004-05-21 13:18:00) [1]
>открываешь окно "выбрать наименование" - все блокируются. Выбрал - разблокировались.

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

Курдль (2004-05-21 13:01:00) [2]

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

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

bushmen (2004-05-21 12:55:00) [3]
>весь сыр-бор о том, чтобы предотвратить такие инцеденты!

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

Курдль (2004-05-21 12:27:00) [4]

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

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

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

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

Rem (2004-05-21 12:18:00) [5]
Про чайники [47]:

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

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

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

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

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

Курдль (2004-05-21 11:46:00) [7]

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

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

Sergey13 (2004-05-21 11:37:00) [8]
>Здесь нужен подход именно с блокировками.
Как раз тут блокировки совсем не нужны. Если два юзера начнут выписывать один товар (что вполне реально), один обломится. А зачем если на складе 1000 чайников и кажду продает по десятку? Нужно простое ограничение на количество>=0 и реакция в проге на возможный облом по этому пункту. И все.

ega23 (2004-05-21 11:30:00) [9]
Здесь нужен подход именно с блокировками.

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

Курдль (2004-05-21 11:15:00) [10]

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

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

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

Курдль (2004-05-21 11:11:00) [12]

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

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

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

bushmen (2004-05-21 11:10:00) [13]
>А иногда у него пос..ть всемени нет

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

ega23 (2004-05-21 11:09:00) [14]
Есть вариант. Делай по таймеру пинг: обновились ли записи в БД. Если обновились, то полный рефреш, раз это тебе так надо. Если нет, то дальше сидишь и дёргаешь коротенький запрос.

Sergey13 (2004-05-21 11:08:00) [15]
2Maxx221177 (21.05.04 10:56) [33]
>Розничный склад с большим ассортиментом.
>Заказ собирается из множества позиций
И все опять упирается в единственный чайник на весь склад который собрались купить сразу 10 человек. 8-)
(недавно был пример с чайником - если кто не в курсе)

Maxx221177 (2004-05-21 11:05:00) [16]
bushmen © (21.05.04 11:02) [36]

Ну иногда сидит и глядит.

А иногда у него пос..ть всемени нет, не то что refresh нажать

Курдль (2004-05-21 11:05:00) [17]

> Розничный склад с большим ассортиментом.
> Заказ собирается из множества позиций

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

bushmen (2004-05-21 11:02:00) [18]
>Розничный склад с большим ассортиментом.

И что, каждый оператор сидит за открытым окном журнала документов и упорно глядит весь день на него? :)
По-моему, он его откроет только тогда, когда к нему подойдет клиент, а потом закроет

Емахо! (2004-05-21 11:00:00) [19]
>>Розничный склад с большим ассортиментом.
>>Заказ собирается из множества позиций

У меня примерно аналогичная задача. :))))) Ток информационная система пишется, которая вообще отслеживает все, несчитая прихода-расхода товара

Емахо! (2004-05-21 11:00:00) [20]
>>Розничный склад с большим ассортиментом.
>>Заказ собирается из множества позиций

У меня примерно аналогичная задача. :))))) Ток информационная система пишется, которая вообще отслеживает все, несчитая прихода-расхода товара

Страницы: 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »