Про обновление .....

← →
AntonVS © (2004-05-13 13:30) [0]

суть трабла в следующем.

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

есть простой подход - обновить весь НД(НД.Refresh)
но это не круто...
трафик кушается... и т.д.

есть два вопроса.

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

делаю это так:
- с сервака в процедурке, сделавщей изменения, генерится POST_EVENT ...
- на клиенте обработчиком события IBEvents1EventAlert выполняется RefreshRecord конкретной записи; НД - IBClientDataSet1, StatusFilter=[usUnModified], перехожу к нужной записи(т.е. к той, что была изменена), делаю RefreshRecord и получаю ошибку - "At beginning of table."

в случай использования IBClientDataSet1.Resync - тишина, т.е. ошибок - нет, но и результата тоже нет.

что не так делаю?

2. в случае INSERT-а, т.е. новая запись кем-то добавленна, нужно обязательно делать Refresh всего НД или можно как-то только одну эту самую новую запись считать?

← →
Курдль © (2004-05-13 13:49) [1]

http://delphimaster.net/view/3-1084251518/

← →
AntonVS © (2004-05-13 14:18) [2]

> Курдль © (13.05.04 13:49) [1]
> http://delphimaster.net/view/3-1084251518/

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

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

← →
Danilka © (2004-05-13 14:31) [3]

> не верю что нет стандартных

а это нестандартная, в большинстве случаев безполезная и даже вредная вещь.

← →
AntonVS © (2004-05-13 14:44) [4]

> а это нестандартная, в большинстве случаев безполезная и даже вредная вещь.

по поводу бесполезная - позвольте не согласиться...

очень даже полезная и не в виде большой толстой кнопки "Обновить"

← →
AntonVS © (2004-05-13 14:45) [5]

← →
Danilka © (2004-05-13 15:00) [6]

Приведи пример когда это на самом деле необходимо. Давать клиенту, что он не просит. Когда на самом деле оправдано увеличение трафика, который будет идти на клиентские машины за которыми никто не сидит, а девушки-юзерши в соседнем кабинете кофу пьют.
И подумай, кому по-башке надают за тормоза сети? Может тем девушкам? Так у них аргумент железный: "мы ничего в программе не делаем".

А если еще учесть, что в гриде отражается, допустим 20 записей, новые записи добавляются в конец и все равно не видны в гриде, где польза? Это вредительство. Если ты его устроишь на крупном предприятии с большим кол-вом клиентов, с большим кол-вом операций, то это реальный шанс потерять работу.

← →
stud © (2004-05-13 15:09) [7]

> Danilka © (13.05.04 15:00) [6]

все зависит от задачи, иногда нужно обновлять набор даже если он юзеру не нужен (а юзер как правило никогда не знает что ему нужно)))

← →
AntonVS © (2004-05-13 15:18) [8]

на счет кофы в соседнем кабинете - это, конечно, правильно, но посмотри: если обновляется одна запись - какой трафик? ->0, даже если клиентов десятки.

а кофа - исключается, т.к. с одной и той же инфой(список остатков на складе) работают одновременно КАК МИНИМУМ 5 клиентов.

опять же на счет Кофы - обновлять только тем, кто реально работает с остатками, например - реагировать на нажатие какой-нибудь клавиши в DBGrid-е, отображающем остатки. или считать когда последний раз что-нибудь делал клиент, если уже полчаса как ничего не делал - ну и не обновлять тогда...

← →
Курдль © (2004-05-13 15:28) [9]

Есть опасения, что единственный оставшийся на складе чайник продадут сразу 5 клиентов? Ну так ты и при "ускоренном обновлении" от этого не застрахуешься! Для этого существует специальная технология блокировок (билетные кассы и т.п.)

← →
AntonVS © (2004-05-13 15:44) [10]

> единственный оставшийся на складе чайник продадут сразу 5 клиентов

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

← →
Danilka © (2004-05-13 15:52) [11]

[10] AntonVS © (13.05.04 15:44)
Хм, а где он видит?
Подходит клиент, говорит: "хочу 5 чайников", оператор заводит новый док-т "реализация", заходит в спецификацию этой реализации заводит новую запись, открывает список товаров и из этого списка выбирает чайник, при этом ей пишется остаток чайников на складе на этот момент, и она говорит клиенту: "извини, дорогой, у нас нет больше чайников".
Дальше они могут хоть 3 часа болтать, клиент ей признается в любви, а потом скажет: "давай в место чайника я набор вилок куплю", она опять открывает таблицу товаров и ищет в ней набор вилок, при этом данные по вилкам будут актуальны на момент открытия.

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

← →
bushmen © (2004-05-13 15:53) [12]

>"я же вижу - вот он мой чайник - 1 шт, а прога говорит нету..., хочу продать

А если в этот момент продавец оформляет телевизор? Зачем ему в гриде информация о чайнике? :)

← →
stud © (2004-05-13 16:11) [13]

> А если в этот момент продавец оформляет телевизор? Зачем
> ему в гриде информация о чайнике? :)

а вдруг он резко передумал и решил оформить чайник?)))

← →
Курдль © (2004-05-13 16:31) [14]

> разумеется при выписки перед продажей - проверка - "сколько
> осталось реально?"...

Видимо это действительно надо реализовывать 3-хзвенкой, противником которой я всегда себя считал (мои клиенты ниччё никогда не продают, а только покупают, покупают, покупают!) :)))

← →
roottim (2004-05-13 16:46) [15]

просто если покупают телевизор, то чайник идет в подарок... а актуальность сколько есть сейчас подарков.. действительно актуальна :))

а по делу... здесь тебе помогут не dbaware компоненты...

← →
AntonVS © (2004-05-14 07:32) [16]

М-да. наблюдается отнюдь не парадоксальная ситуация.
я замечал - подобного рода дискуссии с вопросами про обновление записей в многопользовательских СУБД транспонирутся в некое лирическое отступление и там застревают.

Господа, ну поделитесь уже кто-нибудь опытом пользования метода RefreshRecord

← →
Sergey13 © (2004-05-14 08:30) [17]

2AntonVS © [16]
>я замечал - подобного рода дискуссии с вопросами про обновление записей в многопользовательских СУБД транспонирутся в некое лирическое отступление и там застревают.
Просто никто не хочет натирать веревку мылом человеку, решившему повеситься по неопытности. 8-)

>Господа, ну поделитесь уже кто-нибудь опытом пользования метода RefreshRecord
Нет, сначала ты скажи, зачем тебе это надо, иначе никто не скажет. 8-)

> с одной и той же инфой(список остатков на складе) работают одновременно КАК МИНИМУМ 5 клиентов.
Сколько у тебя товаров на складе? 5, 10, 20? Я думаю побольше. И вероятность продажи 1 последнего чайника сразу 5 клиентам крайне мала. Вот и закладываться надо на исключительность такой ситуации, а не на предпроверку возможности. Наложи ограничение на остаток >=0 и спи спокойно. Это все что нужно сделать в БД. В проге надо также предусмотреть реакцию на это.
В крайнем случае можно подумать о предварительном резервировании товара перед оформлением продажи.

AntonVS © (13.05.04 15:44) [10]
Точно бардак, надо резервировать чайник для продажи
Обновление к этому никакого отношения не имеет.

Господа, давайте примем по умолчанию, что мне все же это нужно...

Помогите же справиться с RefreshRecord.

Нашел дурачков за четыре сольдо...

← →
-SeM- (2004-05-14 10:29) [21]

Мужики, вы о чем?
У вас запрос возвращает в грид 20 (10, 5 ...) тысяч записей? И вам необходимо видеть текущее состояние всех этих записей? Меняйте логику программы, срочно!

Ну а если все таки хочется и варианты с кнопкой (таймером) или [14] не подходит, то в FIBPlus С.Бузаджи можно поизвращаться используя кеш (методы CacheOpen, CacheInsert ...) и несколько датасетов.

> AntonVS

мне пока непонятны след.вещи в твоем объяснении

1. каким образом с пом. POST_EVENT ты извещаешь заинтересованных клиентов об изменениях КОНКРЕТНЫХ записей КОНКРЕТНЫХ таблиц ? Как это у тебя организовано ?

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

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

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

> Digitman © (14.05.04 10:32) [22]

1. в таблицу обновлений - имя таблицы, ID записи, что нужно обновить; POST_EVENT; реакция клиента на POST_EVENT - смотрит в таблице обновлений какую запись необходимо обновить, RefreshRecord.

2. в курсе

> AntonVS © (14.05.04 11:37) [23]

1.

вот он тебе и траффик бестолковый !
до тех пор пока в ФБ не будет реализован параметрический POST_EVENT (вряд ли это будет скоро), лучший выход при такой задаче - реализация 3-хзвенной архитектуры

делаешь апп-сервер , который будет принимать POST_EVENT"ы и шарить по таблице изменений

клиент подключается к апп-серверу и подписывается на уведомления о событиях в интересующих таблицах

апп-сервер при наступлении нужного события асинхронно извещает кл-та о нем и, если нужно, тут же передает конкретные обновленные данные, никаких иных запросов от клиента не требуется

2.

если в курсе, проверяй у себя, рестартуешь ли ты на самом деле транзакцию, в которой открыт НД, после получения POST_EVENT

Да тут трехзвенка нужна, можно еще CallBack на клиента делать, а там проверять подписан ли клиент на событие изменения этой таблицы.

Про обновление ..... Найти похожие ветки