> 356
и все бухгалтеры?

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

> antonn  (09.01.2012 15:45:29)  [29]

И после обновления, ему приходится искать, а где та запись, которую я только
что читал.

> И после обновления, ему приходится искать

он так и сказал - "мне приходится искать"? :)
а мне при автоматическом сборе почты не приходится искать, не смотря на то, что в списке появляются новые строки. Наверное те кто реализовывал интерфейс об этом позаботились :)

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

> Знаток   (10.01.12 00:26) [84]

Знаток - Niel?
Или на винграде подсмотрел?
:)

to Anatoly Podgoretsky ©   (09.01.12 23:26) [82]:

>  ему приходится искать, а где та запись, которую я только
> что читал.

Это да. Если просто надо запомнить на какой записи стояли и после обновления встать туда же, то это мелочь. А вот особенно будет весело, если запись перестанет условию фильтра какого-нибудь удовлетворять. :)

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

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

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

> Наверное те кто реализовывал интерфейс об этом позаботились :)
у них нет изменений по отфильтрованному на клиенте полю. это + к тому что выше.
изменений ИЗВНЕ, причем для локального рекордсета возможно единственному ключевому... ну вот было это 1 записью, с ключём = 1, а стало, усилиями редактора в сети, 1315-и... и найти не по чему... (ключ изменился. помним?)

т.что они кроме заботы об интерфейсе ввели кучу ограничений, с точки зрения нормального клиента субд.

> ты не пользуешься при "сборе почты" возможностями клиента,
>  в полном объеме. не ставишь фильтры, не сортируешь данные,
>  не запрашиваешь по условию, не делаешь объединений, не
> редактируешь то что смотрит сосед

а это все делает человек в сабжевом сообщении? Он так и сказал что все это делает?
кстати, в MS Outlook есть сортировка, группировка.. что, однако, не мешает


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

и ничего, делали, и клиенты не уходили.

> а это все делает человек в сабжевом сообщении? Он так и сказал что все это делает?
а это как раз пофигу, для сферического коня в вакууме, раз он не разъясняет "а зачем", значит отвечающий волен предполагать у него любые "ужасы".  

> однако, не мешает
ты реально не понимаешь? или чисто ради "поспорить"? если второе то честно скажи чтобы я перестал пытаться тебе объяснять.

она во первых мешает... если там сделать правило и раскладывать письма по группам то для них перестает работать уведомление о новых в трей... если конечно не пришло новое письмо во "входящие" вне правил.

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

бурное обсуждение..., а ТС и след простыл...

> Программой пользуются 2-3 тыс. людей, большинство из них
> бесит такой подход,

это значит более 50% юзеров, неужели ~1,5 тыс. человек пожаловались, что нет автообновления?!


> Павел Калугин ©   (09.01.12 15:54) [31]
> Anatoly Podgoretsky ©   (09.01.12 23:26) [82]

+1
Если это к тому же и таблицы.. куча окон, в которых должна обновляться инфа..
имхо, на худой конец, сообщать пользователю, что эти обновления имеются и можно обновить данные..

call-центр, ~ 1000 клиентов
автообновление или его аналог был в ТЗ, послали с автообновлением нафиг. Начальник грамотный у меня, придумал слова нужные :)

+постарались сделать, что бы один оператор не зависел от любого другого.

Зависимость осталась, но сделал (сам делал этот момент) так, что при перезаписи уже измененного поля выходит окно, где написано что запись с момента взятия в работу была изменена. И три варианта записи показаны,
исходный, который юзер взял в работу
который сейчас в БД,
который сейчас у юзера.
(Сделал по аналогии с демкой к ODAC на св-во CashedUpdates у DataSet)
И предлагается выбрать окончательный вариант к записи в БД.
А если что-то успеет изменится, предлагается еще раз это окно. Зациклено до полного исключения конфликта.
Залогированы такие моменты. Судя по логам, никто не видел окно более 2х раз подряд. А два раза видели только при массовых операциях, когда выделяли более 100 записей и говорили обновить какое-то поле. (перевести в др.категорию, например, и передать в другую службу и т.п.)

> это значит более 50% юзеров, неужели ~1,5 тыс. человек пожаловались, что нет автообновления?!
это значит, что пожаловался один... начальник. который не работает, а сидит и "втыкает" в программу ковыряя в носу... т.е. нажать обновить у него рука занята.
те кто реально работает, те получают новое по ходу работы.

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

p.s. жаль только что "весу" при решениях у этого одного гораздо больше чем 50%.

> sniknik ©   (10.01.12 09:46) [93]

да, реально так оно и бывает..

> asail ©   (09.01.12 18:47) [59]
>
> > Павел Калугин ©   (09.01.12 16:24) [49]
>
> > Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ
> КЛИЕНТА?
>
> И че? Разницу между клиентом и пользователем осознаем?

И в чем разница? Данные у пользователя обновляются не по инициативе сервера. Как это реализовано - он сам капу давит или таймер шуршит дело десятое.

> asail ©   (09.01.12 20:42) [62]
>
> > DVM ©   (09.01.12 18:55) [60]
>
> > Автоматическое обновление может быть использовано лишь
> там,
> >  где оно ReadOnly и не связано зависимостями с текущими
>
> > действиями пользователя.
>
> А вот и нет. В качестве примера могу привести сетевые аркадные
> игры, типа Counter Strike и подобных. Что мы тут имеем?
> Во-первых, обновление там более, чем автоматическое - игрок
> практически в реальном времени видит изменения, вызванные
> действиями других игроков. И во-вторых, своими действиями
> очень так даже может влиять на остальных игроков и на ситуацию
> в целом.

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

> asail ©   (09.01.12 21:39) [68]
>
> > sniknik ©   (09.01.12 21:22) [66]
> > > какой бухгалтерии?
> > база, mssql, клиент сервер, 2-3тыс клиентов...
>
> Нифигасе такая бухгалтерия! 2-3тыс клиентов... :))

Неболшая, по сути, булгахтерия. Кстати практически любую учетную систему можно бухгалтерией назвать. И колцентр, в принципе, тоже. Ибо там необходим учет :)

sniknik ©   (09.01.12 18:09) [58]


> именно, и это правильно, но тем не менее есть операции (переоценка)
> которая их меняет. и вот этом "проблема автообновления"
> здесь, нужно менять (раз клиент хочет, но по правилам/логике
> учетной системы меняться не должно, должно быть = как в
> накладной.
> это просто еще один пример когда "не складывается".


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

> один из пользователей обламывался


Причем обламывался сразу же, при заморозке товара, а не при нажатии "Провести транзакцию".