обновление данных при multi-user работе

← →
Dmitry1987 (2012-01-09 01:04) [0]

Каким образом можно решить проблему обновления данных в программах-клиентах при многопользовательской работе с субд (MS SQL Server). Сейчас программа работает так: например, пользователь 1 добавил новую запись. Чтобы в остальных программах-клиентах отобразились изменения другим пользователям нужно нажать на кнопку обновить. Программой пользуются 2-3 тыс. людей, большинство из них бесит такой подход, они хотят, чтобы, например, если пользователь 1 изменил какую-то информацию, у других пользователей эти изменения отобразились автоматом без лишних телодвижений с их стороны.

← →
DVM © (2012-01-09 01:07) [1]

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

и как это по их мнению должно выглядеть? ты поинтересуйся у тех кого это бесит.

← →
sniknik © (2012-01-09 01:41) [2]

работа она вообще бесит...

← →
Германн © (2012-01-09 01:47) [3]

> и как это по их мнению должно выглядеть? ты поинтересуйся
> у тех кого это бесит.

Они захочут и рыбку съесть и ... :)

← →
Германн © (2012-01-09 01:48) [4]

> Dmitry1987 (09.01.12 01:04)
>
> Каким образом можно решить проблему обновления данных в
> программах-клиентах при многопользовательской работе с субд
> (MS SQL Server). Сейчас программа работает так: например,
> пользователь 1 добавил новую запись. Чтобы в остальных
> программах-клиентах отобразились изменения другим пользователям
> нужно нажать на кнопку обновить. Программой пользуются 2-
> 3 тыс. людей, большинство из них бесит такой подход, они
> хотят, чтобы, например, если пользователь 1 изменил какую-
> то информацию, у других пользователей эти изменения отобразились
> автоматом без лишних телодвижений с их стороны.

Начитались, блин фантастики.

← →
antonn © (2012-01-09 01:59) [5]

> Dmitry1987 (09.01.12 01:04)

не сказано про клиента (в смысле софт), делали web-интерфейс и там аяксом переодически запрашивали изменения с сервера, и обновляли гриды. Но там специфика была такая, что частота опроса раз в 2 секунды была достаточна.

← →
Petr V. Abramov © (2012-01-09 02:14) [6]

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

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

← →
antonn © (2012-01-09 02:19) [7]

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

вероятно им хочется автообновления как в чатах (или по аналогии - как автополучение почты. Я вот стал привыкать на работе к почте которая сама "сыпется", хотя дома уже лет 10 использую "ручной режим"). Сидит работник, орудует степплером, а новые строки сами "доставляются" :)

← →
Petr V. Abramov © (2012-01-09 02:35) [8]

> Я вот стал привыкать на работе к почте которая сама "сыпется",

это то самое специфическое исключение - новая почта требует действия (прочитать, забить)

> Сидит работник, орудует степплером, а новые строки сами
> "доставляются" :)

и нафига они ему? нефиг от степлера отвлекаться.

← →
Германн © (2012-01-09 02:58) [9]

> antonn © (09.01.12 01:59)

> Petr V. Abramov © (09.01.12 02:14) [6]

И вы считаете, что поняли нужды автора?
Троешники!

← →
Компромисс © (2012-01-09 10:43) [10]

У нас реализовано то, что надо автору. Правда, для связки Flex-Java. Уведомления мгновенно приходят по RTMP (red5), никаких пингов и прочих извращений, число пользователей практически неограничено. Судя по комментариям, такого в Delphi еще долго не будет...

← →
DVM © (2012-01-09 10:58) [11]

> Компромисс © (09.01.12 10:43) [10]

> число пользователей практически неограничено

"нам то не гони" (c)

> Судя по комментариям, такого в Delphi еще долго не будет.
> ..

Вот причем тут Delphi? И в Делфи легко прикручивается та же librtmp.dll и шли себе уведомления сколько влезет. Только метод странный какой то.
Да, в делфи еще долго не будут применять протокол для передачи медиаданных (причем закрытый, проприетарный, неизвестно как еще там с лицензиями на его версию, сделанную энтузиастами по неполной документации от Adobe), в бухгалтерских программах.

← →
DVM © (2012-01-09 11:02) [12]

Если уж очень хочется уведомлений, то логичнее всего посмотреть на то как это сделано в Extended MAPI у MS. Ни для кого не секрет, что тысячи пользователей MS Outlook практически мгновенно получают уведомления о приходе/удалении/перемещении писем в своих почтовых базах, причем они не делают постоянных перезапросов к базе Exchange. Уведомляет их сервер через UDP, на уведомления лишь надо подписаться. Сами пакеты, содержащие информацию очень компактны и клиентов может быть очень много.

← →
знайка (2012-01-09 11:21) [13]

Если так все критично, можно заюзать Notification Services.

← →
Компромисс © (2012-01-09 11:21) [14]

DVM ©

Red5 with AMF calls less than 1024 bytes every second or so can support 20,000 clients in its sleep.
It is scaled easily also.
Red5 has GNU Lesser General Public License.
К слову, Adobe в курсе насчет использования Red5 одним из наших клиентов и никаких претензий не предъявляет.

> И в Делфи легко прикручивается та же librtmp.dll и шли себе
> уведомления сколько влезет.

Замечательно. Тогда я извиняюсь перед Delphi. Надо было сразу "наехать" персонально на некоторых комментаторов, вопрошающих "зачем это надо" :)

← →
DVM © (2012-01-09 12:03) [15]

> Компромисс © (09.01.12 11:21) [14]

> Надо было сразу "наехать" персонально на некоторых комментаторов,
> вопрошающих "зачем это надо" :)

Да вроде бы наехали на Delphi, совершенно безосновательно. RTMP ведь не заслуга Java или Java сообщества.

Я же все равно вижу затею с немедленным уведомлением пользователей об изменениях в базе сомнительной. Это из той же оперы что нумерация строк в гриде. Вроде бы надо, а зачем объяснить не могут. А потом проблем может создать больше, чем удобств.
Это уже тут обсасывалось несколько раз. И примеры приводились, когда могут возникнуть проблемы.

← →
Омлет © (2012-01-09 13:07) [16]

> Я же все равно вижу затею с немедленным уведомлением пользователей
> об изменениях в базе сомнительной

Задачи разные бывают. Такие широковещательные рассылки иногда нужны.

← →
Компромисс © (2012-01-09 14:30) [17]

DVM © (09.01.12 12:03) [15]

> Да вроде бы наехали на Delphi, совершенно безосновательно.

Согласен. Моя реплика была вызвана "Начитались, блин фантастики."

> RTMP ведь не заслуга Java или Java сообщества.

Ну, red5 (причем абсолютно бесплатно) - заслуга именно Java сообщества. Точнее, авторов red5, которая написана на Java.

> Я же все равно вижу затею с немедленным уведомлением пользователей
> об изменениях в базе сомнительной

Почему? Если у пользователя загружена только что отредактированная запись, почему бы ее сразу не показать в актуальном виде? Во избежание проблем с повторным редактированием. Кстати, данные о том, что другой пользователь начал редактировать какую-то запись, тоже можно передавать по RTMP.

← →
sniknik © (2012-01-09 14:34) [18]

> Надо было сразу "наехать" персонально на некоторых комментаторов, вопрошающих "зачем это надо" :)
от того "зачем", часто зависит "как, и можно/нужно ли вообще".
т.что ты и тут с наездами некстати.

← →
Компромисс © (2012-01-09 14:48) [19]

sniknik © (09.01.12 14:34) [18]

Перечитай [0] и пойми, что здесь не тот случай. Совершенно справедливое требование пользователей.

← →
Petr V. Abramov © (2012-01-09 15:07) [20]

> Компромисс © (09.01.12 14:48) [19]

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

← →
antonn © (2012-01-09 15:10) [21]

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

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

← →
Компромисс © (2012-01-09 15:17) [22]

Petr V. Abramov © (09.01.12 15:07) [20]

Хорошо, допустим, Вы правы и у них "фиговая организация работы". Что Вы предлагаете ТС? Идти к генеральному директору и требовать, чтобы он всё поменял?

← →
sniknik © (2012-01-09 15:26) [23]

> Перечитай [0] и пойми, что здесь не тот случай.
Перечитай [0] и пойми, что здесь вообще нет случая

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

а просят (ну обычно, меня тоже сие не минуло), отслеживание изменений ВСЕГО в зависимости от того куда клиент в этот момент "пялится" (отошел на час пообедать вернулся, а там все актуально), меняют все все ("многопользовательность" и бардак в организации) но чтобы все было правильно (то что ты в этот момент можешь править именно то, что сервер сказал заменить, и это у тебя буквально под рукой поменяется, обычно не учитывают при "ТЗ"),
ну и т.д. частности "по месту", когда говоришь о будущих проблемах, опять обычно, говорят, "ну ты же программист придумай, что нибудь". а тут вот даже считающие себя программистами не видят разницы в организации процесса.

← →
sniknik © (2012-01-09 15:28) [24]

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

← →
sniknik © (2012-01-09 15:30) [25]

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

← →
Компромисс © (2012-01-09 15:30) [26]

sniknik © (09.01.12 15:26) [23]

см. [22].

← →
sniknik © (2012-01-09 15:32) [27]

> см. [22].
см. [24].

← →
Компромисс © (2012-01-09 15:37) [28]

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

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

← →
antonn © (2012-01-09 15:45) [29]

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

Отличный пример того что хочет видеть пользователь. Он хочет видеть изменения в программе которой он пользуется на своем компьютере, так же как он пользуется почтовым клиентом на этом же компе. Ему совершенно пофиг как там устроена почта, он видит интерфейс. И этот интерфейс ему удобен. Получение письма - это изменение в почтовом ящике. Добавление/редактирование/удаление строки в некой таблице на сервере - это изменение.

← →
sniknik © (2012-01-09 15:50) [30]

> Если есть необходимость
наводящий вопрос "а зачем?" как раз и проясняет эту необходимость.

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

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

> Ладно, дальше без меня спорьте.
слив засчитан.

← →
Павел Калугин © (2012-01-09 15:54) [31]

> Dmitry1987 (09.01.12 01:04)
> Программой пользуются 2-
> 3 тыс. людей, большинство из них бесит такой подход, они
> хотят, чтобы, например, если пользователь 1 изменил какую-
> то информацию, у других пользователей эти изменения отобразились
> автоматом без лишних телодвижений с их стороны.

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

← →
sniknik © (2012-01-09 15:57) [32]

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

объясни, и я полностью - ЗА!

← →
Компромисс © (2012-01-09 15:58) [33]

ты менеджер? чего делаешь на сайте программистов?

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

но по сути, ты бы сделал?

Нет, не делал. Я не путаю "неудобство" работы пользователя с отказом от безопасности.

← →
Компромисс © (2012-01-09 16:00) [34]

А как порадует их постоянное мельтешение данных на экране, со скоростью выше чем глазом можно отфиксировать :)

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

> А как будет рад владелец сервера от возросшей в разы нагрузки
> из-за генерации веером сообщений на каждый чих
> А какое спасибище скажут сисадмины -можешь и не унести такое
> спасибо.

А это клиента не волует и не должно волновать

← →
Компромисс © (2012-01-09 16:01) [35]

нежули = неужели
волует = волнует

← →
Павел Калугин © (2012-01-09 16:02) [36]

> Компромисс © (09.01.12 15:58) [33]
> ты менеджер? чего делаешь на сайте программистов?
>
> Я не менеджер, но точно знаю, что если бы мы отказались
> делать так, как хочет клиент, он бы просто обратился к другой
> фирме.

Еще раз - 2-3 тысячи пользователей. Вполне вероятно что в тебении секунды более 25 пользователей будут терзать один и тот же набор данный а 26-й на том же наборе пытатся смотреть кино. И сделать так ибо клиент это хочет?

← →
Павел Калугин © (2012-01-09 16:05) [37]

> А это клиента не волует и не должно волновать

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

← →
Компромисс © (2012-01-09 16:06) [38]

> И сделать так ибо клиент это хочет?

Конечно. Клиента интересует текущее состояние. На форексах разных информации даже больше и ничего, нормально.

← →
Petr V. Abramov © (2012-01-09 16:08) [39]

> Компромисс © (09.01.12 15:58) [33]

В шумном балагане любит веселиться И пожрать отменно радостный народ. Левка-Паганини, если разозлится, Он своею скрипкой всех с ума сведет. А если сунуть четвертак, Так он сыграет и не так.
;)

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

← →
Павел Калугин © (2012-01-09 16:09) [40]

> На форексах разных информации даже больше и ничего, нормально

От не зря я упоминал про специфический класс задач. Форексы и прочие биржи отдают котировки и т.п. ПО ЗАПРОСУ а не ПО ОБНОВЛЕНИЮ.

← →
Компромисс © (2012-01-09 16:10) [41]

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

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

← →
Petr V. Abramov © (2012-01-09 16:12) [42]

> На форексах разных информации даже больше и ничего, нормально.

бывает и такое, но в 25 раз реже, чем не бывает.
ТС же не хочет дать ответ на вопрос зачем ему это надо.

← →
Компромисс © (2012-01-09 16:13) [43]

Petr V. Abramov © (09.01.12 16:08) [39]

> - заказчик расписался, что сам несет ответсвенность за свои
> хотелки
> - готов платить за то, чтобы их потом переделывать

Конечно. У нас клиент загружает несколько сот тысяч строк и постоянно видит текущие изменения. Причем ему так понравилось, что он нас попросил и к другим скринам добавить автообновление. И я не нахожу это странным.

← →
Компромисс © (2012-01-09 16:15) [44]

Павел Калугин © (09.01.12 16:09) [40]

Форекс лишь демонстрирует, что нет ничего принципиально плохого в "мельтешении". RTMP демонстрирует, что сетка/сервер справится с 3 тысячами пользователей. Выше в ветке я писал, что один red5 сервер поддерживает до 20 тысяч подключений=пользователей.

← →
Petr V. Abramov © (2012-01-09 16:16) [45]

> Причем ему так понравилось, что он нас попросил и к другим
> скринам добавить автообновление.

ну чем бы дитя ни тешилось, лишь бы не руками

> И я не нахожу это стран

а вот это уже хуже
:)

← →
Компромисс © (2012-01-09 16:17) [46]

> ТС же не хочет дать ответ на вопрос зачем ему это надо.

Он уже дал ответ. Это надо не ему, а многим из тех 3 тысяч пользователей, кого бесит ежеминутное нажатие кнопки рефреш. Возможно, можно по таймеру нажиамть программно рефреш, но я не уверен, что нагрузка на сетку будет меньше. Тогда уже придется при рефреше отдавать порцию изменившихся данных, а на клиенте производить слияние.

← →
Petr V. Abramov © (2012-01-09 16:21) [47]

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

а можно для начала попробовать убрать кнопку рефреш, может, никто и не заметит :)

← →
знайка (2012-01-09 16:24) [48]

У нас тоже есть места в системе где есть "автообновление", и мест не мало, тоже заказ, и ничего в этом странного мы не находим. И не форекс совсем.
Как его сделать - таймером, оповещением, все закачивать, или только изменения и т.д. и т.п., это уже другой вопрос.
Что прицепились непонятно...

← →
Павел Калугин © (2012-01-09 16:24) [49]

> Форекс лишь демонстрирует, что нет ничего принципиально
> плохого в "мельтешении". RTMP демонстрирует, что сетка/сервер
> справится с 3 тысячами пользователей. Выше в ветке я писал,
> что один red5 сервер поддерживает до 20 тысяч подключений=пользователей.
>

Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ КЛИЕНТА?

← →
sniknik © (2012-01-09 16:28) [50]

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

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

← →
sniknik © (2012-01-09 16:30) [51]

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

← →
antonn © (2012-01-09 16:39) [52]

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

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

> ТС же не хочет дать ответ на вопрос зачем ему это надо.

а нам это не надо знать

← →
знайка (2012-01-09 16:39) [53]

Вот алигарх покупает Pagani Zonda дочери малолетней, спросите у него "а зачем?". :)

← →
Компромисс © (2012-01-09 16:41) [54]

Павел Калугин © (09.01.12 16:24) [49]

> Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ КЛИЕНТА?

Естественно. Практически невозможно оповещать миллионы клиентов.

sniknik © (09.01.12 16:28) [50]

> сделаешь?

Нет, конечно. А вообще не вижу связи с предыдущей дискуссией. Если бы автообновление иногда/часто работало неправильно, я бы тоже его отказался делать. Ибо я отличаю неудобство не только от нарушения безопасности, но и от некорректности работы :)

← →
Компромисс © (2012-01-09 16:41) [55]

← →
sniknik © (2012-01-09 16:53) [56]

> Ибо я отличаю неудобство не только от нарушения безопасности, но и от некорректности работы :)
не везде... только где тебе хочется -
первый пример
sniknik © (09.01.12 15:57) [32]
и безопасно, и корректно. и удобно всем... кроме того кто "по ушам получит", за невнимательность, т.е. тот кто реально с программой работает (а вот фенечки разные, типа обсуждаемой, это обычная менеджерская задумка, при не незнании того как оно работает, т.е. "пятиминутное знакомство, и решение по верхам").
причем делали бы чат, почтового клиента, одной таблицы, только добавления ... да не вопрос. но тут про общего клиента, по работе с субд, и изменения вообще. разница однако.

← →
Компромисс © (2012-01-09 17:05) [57]

sniknik © (09.01.12 16:53) [56]

> не везде... только где тебе хочется -
> первый пример
> sniknik © (09.01.12 15:57) [32]

Посмотри внимательнее. Это было обращено не ко мне и я не ответил. Я в любом случае не ответил бы, потому что не понял суть проблемы. Лет 10 назад я участвовал в написании комплекса программ товарно-денежного учета, так у нас там при списании можно было редактировать все цены (и закупочные), которые применялись только для текущей операции. То есть цены по остаткам товары вообще не менялись.

← →
sniknik © (2012-01-09 18:09) [58]

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

← →
asail © (2012-01-09 18:47) [59]

> Павел Калугин © (09.01.12 16:24) [49]

> Ну и кому я писал, что биржи отдают данные ПО ЗАПРОСУ КЛИЕНТА?

И че? Разницу между клиентом и пользователем осознаем?

> sniknik © (09.01.12 16:28) [50]

Страшная вещь, эти ваши фискальники! Как вспомню - так вздрогну... :)

> sniknik © (09.01.12 16:30) [51]

> "а зачем" хотим знать, ясности хотим, можно ли, нужно ли,
> оправдано ли это делать

Логично. Однако, это не помешало сразу послать идеи ТС в топку, так и не получив вожделенной ясности.
Весь дальнейший спор получился о том, нужен ли сферическому коню хвост... :)

← →
DVM © (2012-01-09 18:55) [60]

Автоматическое обновление может быть использовано лишь там, где оно ReadOnly и не связано зависимостями с текущими действиями пользователя. Т.е на тех же биржах - есть графики и есть грубо говоря у чела кнопки покупаем продаем, то что он нажмет кнопку покупаем или продаем НЕ ГАРАНТИРУЕТ того что он купит или продаст имено по той цене что он только что увидел, так как есть более быстрые товарищи у которых более быстрые серверы и специально натасканные программы сами кликают на кнопки продаем покупаем в зависимости от условий и сидят они в соседнем доме от датацентра на котором биржевые сводки крутятся.

← →
sniknik © (2012-01-09 19:11) [61]

> Логично. Однако, это не помешало сразу послать идеи ТС в топку, так и не получив вожделенной ясности.
> Весь дальнейший спор получился о том, нужен ли сферическому коню хвост... :)
не путай причину и следствие. ответы такие были как раз потому, что вопрос о "сферическом коне". просто "возникла необходимость", без описания относительно чего, к чему применяется, зачем в конце концов. это признак коня в вакууме.

← →
asail © (2012-01-09 20:42) [62]

> DVM © (09.01.12 18:55) [60]

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

А вот и нет. В качестве примера могу привести сетевые аркадные игры, типа Counter Strike и подобных. Что мы тут имеем? Во-первых, обновление там более, чем автоматическое - игрок практически в реальном времени видит изменения, вызванные действиями других игроков. И во-вторых, своими действиями очень так даже может влиять на остальных игроков и на ситуацию в целом.

> sniknik © (09.01.12 19:11) [61]

Это больше относилось к
> Германн © (09.01.12 01:48) [4]

Наиболее логичным было бы всеж уточнить у ТС задачу, а уж потом поминать фантастику всуе... :)

← →
DVM © (2012-01-09 20:51) [63]

> asail © (09.01.12 20:42) [62]

вот и будет вместо бухгалтерии Counter Strike сплошной.

← →
antonn © (2012-01-09 21:14) [64]

> вот и будет вместо бухгалтерии Counter Strike сплошной.

какой бухгалтерии?

← →
sniknik © (2012-01-09 21:20) [65]

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

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

← →
sniknik © (2012-01-09 21:22) [66]

> какой бухгалтерии?
база, mssql, клиент сервер, 2-3тыс клиентов... игра? 2+2?

но вообще, хреновой бухгалтерии, раз дошли до подобных вопросов.

← →
antonn © (2012-01-09 21:27) [67]

> база, mssql, клиент сервер, 2-3тыс клиентов... игра? 2+2?

call-центр
фантазии не хватает на что либо другое кроме "бухгалтерии"? :)

← →
asail © (2012-01-09 21:39) [68]

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

Нифигасе такая бухгалтерия! 2-3тыс клиентов... :))

← →
DVM © (2012-01-09 21:39) [69]

> antonn © (09.01.12 21:27) [67]

> call-центр
> фантазии не хватает на что либо другое кроме "бухгалтерии"?
> :)

фантазии хватает, а call центров с таким количеством операторов я лично не видел, хотя был во многих.

← →
DVM © (2012-01-09 21:40) [70]

> asail © (09.01.12 21:39) [68]

> Нифигасе такая бухгалтерия! 2-3тыс клиентов... :))

ГОСПЛАН

← →
asail © (2012-01-09 21:40) [71]

> DVM © (09.01.12 21:39) [69]

> фантазии хватает, а call центров с таким количеством операторов
> я лично не видел

А бухгалтерию видел?

← →
asail © (2012-01-09 21:41) [72]

> DVM © (09.01.12 21:40) [70]

> asail © (09.01.12 21:40) [71]

Вот видишь, как нам тут автообновления не хватает? :)

← →
asail © (2012-01-09 21:44) [73]

> sniknik © (09.01.12 21:22) [66]

> но вообще, хреновой бухгалтерии, раз дошли до подобных вопросов

> DVM © (09.01.12 21:40) [70]

> ГОСПЛАН

Сошлось. Ну вот и выяснили, чем ТС занимается...

← →
antonn © (2012-01-09 21:44) [74]

> DVM © (09.01.12 21:39) [69]
>
>
> > antonn © (09.01.12 21:27) [67]
>
>
> > call-центр
> > фантазии не хватает на что либо другое кроме "бухгалтерии"?
>
> > :)
>
> фантазии хватает, а call центров с таким количеством операторов
> я лично не видел, хотя был во многих.

но это ведь не значит что их нет? :)

← →
DVM © (2012-01-09 21:44) [75]

> asail © (09.01.12 21:41) [72]

> Вот видишь, как нам тут автообновления не хватает? :)

теперь ясно почему плановая экономика в СССР не пошла - автообновления не было, не успевали все запланировать как надо, отсюда дефицит и прочие беды.

← →
asail © (2012-01-09 21:47) [76]

> DVM © (09.01.12 21:44) [75]

Заметь, у них еще не только Counter Stik"a, но даже, обычной косынки небыло... А то, вообще бы - адъ! :)

← →
antonn © (2012-01-09 21:55) [77]

зато чай уже был изобретен :)

← →
sniknik © (2012-01-09 22:00) [78]

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

← →
sniknik © (2012-01-09 22:05) [79]

+
в лучшие годы правда, счаз правда много меньше ;(
(развалились в связи с кризисом на 4 самостоятельных конторы).

← →
знайка (2012-01-09 22:14) [80]

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

← →
sniknik © (2012-01-09 22:35) [81]

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

← →
Anatoly Podgoretsky © (2012-01-09 23:26) [82]

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

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

← →
antonn © (2012-01-10 00:01) [83]

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

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

← →
Знаток (2012-01-10 00:26) [84]

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

← →
Германн © (2012-01-10 00:32) [85]

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

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

← →
vuk © (2012-01-10 00:34) [86]

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

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

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

← →
sniknik © (2012-01-10 01:02) [87]

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

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

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

← →
sniknik © (2012-01-10 01:10) [88]

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

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

← →
antonn © (2012-01-10 01:24) [89]

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

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

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

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

← →
sniknik © (2012-01-10 08:10) [90]

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

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

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

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

← →
MonoLife © (2012-01-10 08:11) [91]

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

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

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

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

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

← →
OW © (2012-01-10 08:44) [92]

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

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

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

← →
sniknik © (2012-01-10 09:46) [93]

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

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

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

← →
MonoLife © (2012-01-10 09:52) [94]

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

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

← →
Павел Калугин © (2012-01-10 10:27) [95]

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

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

← →
Павел Калугин © (2012-01-10 10:30) [96]

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

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

← →
Павел Калугин © (2012-01-10 10:37) [97]

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

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

← →
Компромисс © (2012-01-10 10:39) [98]

sniknik © (09.01.12 18:09) [58]

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

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

← →
Компромисс © (2012-01-10 10:41) [99]

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

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

← →
Компромисс © (2012-01-10 10:44) [100]

DVM © (09.01.12 18:55) [60]

Автоматическое обновление может быть использовано лишь там, где:
1) этого хочет клиент
2) это технически возможно

← →
Компромисс © (2012-01-10 10:50) [101]

vuk © (10.01.12 00:34) [86]

> А вот особенно будет весело, если запись перестанет условию
> фильтра какого-нибудь удовлетворять. :)

У нас такое бывает. Но:
1) если запись была в процессе редактирования, то она не могла поменяться, потому как при входе в режим редактирования она локируется (не в БД, а через RTMP) и никакой другой клиент не может ее редактировать
2) иначе позиция курсора не меняется
В результате, 1 и 2 приводят к тому, что позиция курсора никогда не меняется :)

← →
Компромисс © (2012-01-10 10:53) [102]

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

У нас разное понимание отображения нового. Не должен экран "прыгать", подсвечивая красным измененные строки, а фиолетовым измененные значения. Экран остается таам же, где он был. Если в текущем экране есть измененные строки, они актуализируется. Без всяких подсвечиваний (если не требуется по ТЗ, конечно). Если очень надо узнать именно изменения, то можно где-то добавить статус "Изменилось N строк" с кнопкой "Просмотреть изменения"

← →
Компромисс © (2012-01-10 10:55) [103]

> (ключ изменился. помним?)

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

← →
Компромисс © (2012-01-10 10:58) [104]

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

А не удобнее ли было бы пользователям, если бы при редактировании строки другие пользователи не могли бы инициировать редактирование той же строки?

← →
sniknik © (2012-01-10 10:59) [105]

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

← →
Компромисс © (2012-01-10 11:05) [106]

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

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

← →
Компромисс © (2012-01-10 11:07) [107]

> Приведи, пожалуйста, пример, когда без автообновления работает,
> а с ним - проблемы?

Кстати, с точик зрения формальной логики, этого будет недостаточно, чтобы доказать, что автообновление всегда плохо. А вот мне достаточно привести пример, когда автообновление реально помогает (не с read only данными), и я его уже приводил, а он опровергнут не был.

← →
vuk © (2012-01-10 11:08) [108]

to Компромисс © (10.01.12 10:53) [102]:

> У нас такое бывает. Но:1) если запись была в процессе редактирования,
> то она не могла поменяться, потому как при входе в режим
> редактирования она локируется (не в БД, а через RTMP) и
> никакой другой клиент не может ее редактировать2) иначе
> позиция курсора не меняетсяВ результате, 1 и 2 приводят
> к тому, что позиция курсора никогда не меняется :)

А вот ситуация:
1. Некто Петя получил список каких-то операций в определенном состоянии и сидит их спокойно изучает безо всякого редактирования.
2. Некто Вася изменяет состояние операции, которую в данный момент просматривает Петя.

Вопрос. Что должно произойти у Пети, если работает система автообновлений?

← →
Компромисс © (2012-01-10 11:21) [109]

vuk © (10.01.12 11:08) [108]

> А вот ситуация:
> 1. Некто Петя получил список каких-то операций в определенном
> состоянии и сидит их спокойно изучает безо всякого редактирования.
>
> 2. Некто Вася изменяет состояние операции, которую в данный
> момент просматривает Петя.
>
> Вопрос. Что должно произойти у Пети, если работает система
> автообновлений?

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

← →
знайка (2012-01-10 11:21) [110]

> А вот ситуация:
И что такого в этой ситуации? ситуация как ситуация, ну актуализировались данные, ну и что, волосы, как говорили тут, рвать сразу надо?
У нас в такой ситуации не Вася, а несколько десятков сервисов в режиме 24/7, и все волосатые до сих пор.

← →
знайка (2012-01-10 11:24) [111]

Читаешь и складывается ощущение, мол кто уже столкнулся с необходимостью, то криминала не видит, остальные в панике. :)

← →
vuk © (2012-01-10 11:27) [112]

to Компромисс © (10.01.12 11:21) [109]:

> Если Петя изучает список в том же режиме, что используется
> для обычной работы (редактирования), то он увидит новое
> состояние.

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

← →
sniknik © (2012-01-10 11:28) [113]

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

← →
sniknik © (2012-01-10 11:29) [114]

> Повторяю еще раз.
не старайся, не поймут, им это не выгодно...

← →
Компромисс © (2012-01-10 11:40) [115]

vuk © (10.01.12 11:27) [112]
Повторяю еще раз. Состояние - критерий выборки у Пети. Состояние изменилось. После обновления увидит ли Петя запись, которую изучал до изменения состояния?

Странный вопрос. Автообновление не реализовано автоматически каким-то стандартным компонентом, поэтому поведение зависит от того, как мы его реализуем. А реализовать мы можем по-разному, в зависимости от ТЗ. Можно запретить удаление из отображаемого набора текущей строки (кстати, а зачем, ведь строки уже нет), можно показывать старое ее значение при редактировании другим пользователем (кстати, а зачем, ведь зстарые начения уже не вернешь, хотя...), можно показывать новое значение (самое правильное).
В том же Flex типичная реализация проста до безобразия - меняется элемент коллекции (после поиска по ключу) и всё... Даже рефреш вызывать не надо :)

sniknik © (10.01.12 11:29) [114]

> > Повторяю еще раз.
> не старайся, не поймут, им это не выгодно...

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

← →
Компромисс © (2012-01-10 11:42) [116]

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

У нас работа клиента вообще не завязана на БД и тем более какие-то там таблицы. И это правильно ИМХО. Вон мы недавно на nosql перенесли кое-что, клиентов даже менять не пришлось :) Data Transfer Object - наше всё :)

← →
vuk © (2012-01-10 11:59) [117]

Компромисс © (10.01.12 11:40) [115]:

> Можно запретить удаление из отображаемого набора текущей
> строки

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

> (кстати, а зачем, ведь строки уже нет)

Строка есть, но в другом состоянии. Это повод отобрать у Пети возможность изучать операцию?

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

Дело не в том, какое состояние строки видит пользователь, а в том, видит ли он строку вообще.

> можно показывать новое значение (самое правильное).

Новое значение чего? Состояние строки не соответствует критерию выборки.

> В том же Flex типичная реализация проста до безобразия -
> меняется элемент коллекции (после поиска по ключу) и всё.
> .. Даже рефреш вызывать не надо :)

Не надо путать рабочий процесс пользователя с внутренними механизмами библиотек.

← →
Компромисс © (2012-01-10 12:07) [118]

vuk © (10.01.12 11:59) [117]

На все вопросы - один ответ: в зависимости от ТЗ. У нас, например, редактируемая запись отображается всегда, даже если в процессе редактирования она перестает удовлетворять фильтру.
На казуистику тратить время неохота, уж извините.

← →
vuk © (2012-01-10 12:24) [119]

to Компромисс © (10.01.12 12:07) [118]:

> У нас, например, редактируемая запись отображается всегда,
> даже если в процессе редактирования она перестает удовлетворять
> фильтру.

Я специально сказал, что запись не редактируется. :)

> На казуистику тратить время неохота, уж извините.

Это не казуистика, это вопросы, которые возникают сразу, как только кто-то говорит "а давайте прикрутим автообновление!". По крайней мере у меня возникают. Фигня в том, что однозначного ответа на них нет. Потому, что там, где нужно активное взаимодействие с пользователем в системах обработки данных, мы либо ломаем кому-то рабочий процесс либо сводим смысл автообновлений к нулю.

← →
Компромисс © (2012-01-10 12:34) [120]

vuk © (10.01.12 12:24) [119]

Раз, не казуистика, можно и продолжить :)
У нас клиенты загружают до 400 тысяч строк с режимом автообновления. Знаем, что плохо, но пока переубедить не получается. Даже с такими размерами проблем не возникает - Петя смотрит на экран, Васи меняют данные, Петя продолжает смотреть на экран. Стандартные компоненты "умные", чтобы не рисовать то,Ю что находится за пределами экаран, торможений нет. Если возникают вопросы, на которые "однозначного ответа нет", мы предлагаем возможные варианты заказчику и он делает свой выбор. Всегда видит актуальное состояние, никогда не происходит перезаписи изменений и прочих типичных многопользовательских проблем.

> В таком случае, когда наступит момент, подходящий для того,
> чтобы строка таки пропала из выборки, как несоответствующая
> критерию?

Это не наш случай, у нас строка исчезает сразу. Всегда показывается актуальное состояние. Текущая строка может исчезнуть, если она удалена или не удовлетворяет больше фильтру. Это уже будет ответом на
> Новое значение чего? Состояние строки не соответствует критерию
> выборки.

> Не надо путать рабочий процесс пользователя с внутренними
> механизмами библиотек.

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

← →
Ega23 © (2012-01-10 12:38) [121]

Ух-ты, какой тут прячь опять идёт!!!
И лица одни и те же...

1. Автообновление - ничего хорошего, равно как и ничего плохого в этом нет.
2. Автообновление плохо реализуется с привычными DAC-ами, по-хорошему надо протокол свой писать + трёхзвенку. Если такая архитектура выбрана изначально - нет проблем. Если нет - считай, что с нуля писать надо. Не каждый заказчик будет готов оплатить такую работу.
3. Я бы не хотел пользоваться программой в том виде, как она описана в [0]. Это будет Адъ и Израиль.

← →
sniknik © (2012-01-10 12:51) [122]

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

p.s. почти реальное "тз".

← →
Компромисс © (2012-01-10 12:54) [123]

sniknik © (10.01.12 12:51) [122]

Это к чему? Может, по автообновлению еще и шины на зимние поменять? :)

← →
sniknik © (2012-01-10 12:58) [124]

> Это к чему? Может, по автообновлению еще и шины на зимние поменять? :)
я чуть не с самого начала говорил, если не указаны критерии, четкое "ТЗ" (ответ на "а зачем"), то каждый воспринимает вопрос автора как ему вздумается. я максимально полно, везде где возможно должно авто обновятся (пример и фильмов с исчезающим удаляемым документом, на основе которых дают подобное).

ну так как насчет вариантов?

← →
sniknik © (2012-01-10 12:59) [125]

и кстати "клиент всегда прав" ваши слова.

← →
vuk © (2012-01-10 13:02) [126]

to Компромисс © (10.01.12 12:34) [120]:

> У нас клиенты загружают до 400 тысяч строк с режимом автообновления.

Ужос. И что, есть хоть один человек, который в реальности все эти 400 тыс. просматривает с разумной целью? У нас, пожалуй, несколько сотен записей в выборке - уже повод придумывать средства фильтрации на серверной стороне.

> Это не наш случай, у нас строка исчезает сразу.

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

← →
знайка (2012-01-10 13:09) [127]

> Представляю себя на месте пользователя. Сижу втыкаю на экран..
https://www.bwin.com/ru/livebets.aspx
И пользователей миллионы. автообновление по полной, все пропадает, появляется, мигает и звуки издает. Никаких проблем ни у пользователей ни у разработчиков.

← →
Компромисс © (2012-01-10 13:12) [128]

sniknik © (10.01.12 12:58) [124]

Твое ТЗ не имеет никакого отношения к [0], в котором всё ясно.

sniknik © (10.01.12 12:59) [125]

Лучше другой вариант - "Любой каприз за Вашт деньги" :)

vuk © (10.01.12 13:02) [126]

Клиенты часто идут свеху вниз и просматривают/редактируют список. Они один раз загружают все данные (минута-две), пока чай пьют, потом уже только работают и не хотят времени терять. Учитывая, автообновление, они могут неделями не выключать компьютер. Фильтрация на клиенте очень быстрая, даже быстрее, чем на сервере, учитывая, что есть сложная система контроля доступа и пользователь не всё должен видеть (мягко говоря).

> И тут фигак - обновление свалилось, смотрю почему-то уже
> в какое-то другое место

Есть специфика - добавлений гораздо меньше, чем редактирований. Фильтруют обычно по естественному ключу, который не редактируется. Плюс структура не плоская, а иерархическая (4-5 уровней вложенности). Поэтому пользователю достаточно удобно - они обычно не больше 100 записей раскрывают, потом сворачивают нод и открывают другой, чтобы посмотреть другие 100 записей. А в это время в свернутых нодах невидимо для пользователя работает автообновление...

← →
Ega23 © (2012-01-10 13:13) [129]

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

Это read-only данные.

← →
vuk © (2012-01-10 13:15) [130]

to знайка (10.01.12 13:09) [127]:

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

Этол не система обработки данных. Скорее система оповещения, типа информационного табло. В похожих случаях (но в сильно другой области) у нас автообновление тоже есть.

← →
Ega23 © (2012-01-10 13:15) [131]

> Есть специфика - добавлений гораздо меньше

Вот именно. Есть специфика. Универсальный вариант - по запросу. Автообновление - не универсальный вариант.

← →
asail © (2012-01-10 13:23) [132]

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

1. Вполне возможна.
2. Существуют.
3. Тут нет противников. Тут есть масса народа, которая через стадию "Вася данные изменил, а у меня сразу всё обновилось" уже проходили и не раз. И в большинстве случаев как раз для автообновления должны быть довольно веские причины, а не наоборот.

← →
знайка (2012-01-10 13:28) [134]

> Этол не система обработки данных.
Так вы сами про ридонли ситуацию привели.
И еще, там ставки делаешь, и оно редактируется, и обновляется автоматически, т.е. если ставку заблокировали на сервере, то и в купоне она либо заблокируется либо исчезнет, смотря как реализованно.

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

Правильно, и я эти довольно веские причины уже описывал выше:
1) Заказчик это хочет
2) Это технически возможно.

> Павел Калугин © (10.01.12 10:27) [95]

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

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

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

И все пользователи сразу увидят блокировку, а не только ты.
Не смешно.

> Ega23 © (10.01.12 13:27) [133]

Полностью согласен. Об чем и речь...

> И в большинстве случаев как раз для автообновления должны
> быть довольно веские причины, а не наоборот

И кто-то тут говорил обратное? Я, видимо, пропустил... :)

← →
знайка (2012-01-10 13:35) [139]

> И все пользователи сразу увидят блокировку, а не только
> ты.
> Не смешно.
Собственно, да, а что такого?
Если вася из соседней сделал ставку, и при этом лимит ставок исчерпали, то таки да все об этом узнают. Там ваще ньюансов много.

>
> Правильно, и я эти довольно веские причины уже описывал
> выше:
> 1) Заказчик это хочет
> 2) Это технически возможно.

И тебе уже неоднократно отвечали, как и с редактированием в гриде:
1) Заказчик готов это оплатить
2) Заказчик готов оплатить потом переделку этого "взад", если он осознает, что хотел "странного".
При выполнении этих пунктов - пуркуа бы и не па?
"Желание клиента - закон" выполняется только в одном случае: это действительно клиент, а не "потенциальный клиент".

> Естественно. Тогда об чем спор вообще? :)

Да нету никакого спора.
Но, согласись, в случае [0] с вероятностью 99% - это тупо незнание технологий, архитектур и вообще дилетантство.

> Но, согласись, в случае [0] с вероятностью 99% - это тупо
> незнание технологий, архитектур и вообще дилетантство.

Не соглашусь. С вероятностью 1%. Наверное, об этом и спор :) У разных людей разный опыт. Если на экране есть кнопка "Refresh", то должен быть и checkbox "AutoRefresh"

+ еще комбобокс "Каждые N секунд"

> Ega23 © (10.01.12 13:40) [142]

> Да нету никакого спора.

Спор есть, т.к. некоторые товарищи сразу отнесли саму возможность автообновления в разряд фантастики.

to Компромисс © (10.01.12 13:12) [128]:

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

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

> Фильтрация на клиенте очень быстрая, даже быстрее, чем на
> сервере,

Что-то слабо себе представляю ситуацию, в которой система фильтрации на клиенте будет работать быстрее, чем на сервере. Особенно, если критерий подразумевает некие вычисления по связанным данным.

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

У нас тоже. Но работает это все, сюрпрайз, на уровне сервера. А клиентский код о системе контроля доступа к данным, как правило, вообще не догадывается. Правда, каким боком эт к автообновлениям - мне вообще не понятно. :)

> то должен быть и checkbox "AutoRefresh"
> + еще комбобокс "Каждые N секунд"

Это цепляется за 2 секунды. Речь не об авторефреше, а о событийной модели. а это уже не так просто и однозначно.

to знайка (10.01.12 13:28) [134]:

> Так вы сами про ридонли
> ситуацию привели.

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

to Компромисс © (10.01.12 13:46) [143]

> Если на экране есть кнопка
> "Refresh", то должен быть и checkbox "AutoRefresh"

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

> asail © (10.01.12 13:29) [136]
>
> > Павел Калугин © (10.01.12 10:27) [95]
>
> > > Разницу между клиентом и пользователем осознаем?
> >
> > И в чем разница? Данные у пользователя обновляются не
> по
> > инициативе сервера. Как это реализовано - он сам капу
> давит
> > или таймер шуршит дело десятое.
>
> Вот это ты пользователю объясни... Еще раз, пользователю
> по-барабану, сервер ли рассылает сообщения об изменениях
> или клиент стучится до сервера по таймеру. Да хоть, сисадмин
> будет каждые две минуты с флешкой прибегать и обновлять
> данные... Все это - различные способы технической реализации
> одной и той же функциональности, и с точки зрения пользователя,
> значения не имеют.

Сээр, ну вы просто пользователь? Ну тогда Вам все равно. Иначе сами должны понимать разницу между

> если пользователь 1 изменил какую-то информацию, у других
> пользователей эти изменения отобразились автоматом

и когда клиентское приложение отправляет запрос на получение обновленных данных (по капе или как это абсолютно все равно)

> 400 тыс записей не вываливаются из реальных выборок нигде.
> Они не нужны.

Мне тоже. Клиент хочет :)

> Что-то слабо себе представляю ситуацию, в которой система
> фильтрации на клиенте будет работать быстрее, чем на сервере.
> Особенно, если критерий подразумевает некие вычисления
> по связанным данным.

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

> Но работает это все, сюрпрайз, на уровне сервера.

Обижаешь :) У нас всё тоже очень серьезно в плане безопасности. Детали не скажу, конечно :)

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

> asail © (10.01.12 13:54) [145]
>
> > Ega23 © (10.01.12 13:40) [142]
>
> > Да нету никакого спора.
>
> Спор есть, т.к. некоторые товарищи сразу отнесли саму возможность
> автообновления в разряд фантастики.

Не совсем. Дословно - неоправданные требования автообновления отнесены в область бреда заказчика. Со всеми вытекающими. Как выше Олег писал, если заказчик регулярно оплачивает реализацию своего очередного бреда и адекватно переносит сроки сдачи - почему бы и нет. Но итоговым счетом и сроками заказчик все равно будет не доволен

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

вот и выходит единственное кому это нужно (в этом варианте) это бездельничающему начальнику.

> основная фишка аппаратов Блэкберри в том, что там письма приходят мгновенно
всем, или все-таки адресно?

sniknik © (10.01.12 14:17) [154]

Этот пример можно и в другую сторону использовать. Зачем читать документ, который уже был удален???

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

Ну не только. В моём очень конкретном случае - дежурному прапорщику на пульте контроля. Всякие сообщения от датчиков смотреть. Где-то тревога (по различным причинам), где-то warning, мол, в самотестирование ушло, где-то просто информационные сообщения.
Но, опять же, это исключительно read-only режим. И не более N записей на оперативном экране. Надо больше - будьте любезны в архив, с фильтрами, условиями выборки и т.п.

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

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

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

почему бы и нет? Вот у меня в notepad++ был открыт некий файл. Который я потом взял и удалил с диска. Почему он должен у меня закрыться в notepad?

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

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

Ок, в таком случае обновление не нужно. Возможно, временно не нужно.

> но вот как то я ее не воспринимаю как программу по работе
> с субд

Ну скажем так, это небольшая часть программы.
И там я, дабы не менять архитектуру, тупо на таймер повесил выборку записей, время которых больше максимального в последней выборки. Кстати, тоже ещё те пляски с бубном были с MSSQL и его 0, 3 и 7 дискретами в миллисекундах.

Ega23 © (10.01.12 14:33) [158]

Речь про многопользорвательские программы. Сидишь, читаешь анекдоты в Notepad, в это время начальник удаляет у тебя соответствующий файл. В идеале, Notepad должен написать "Файл был удален пользователем "Big Boss" с комментарием "Живо работать!" :)

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

> Речь про многопользорвательские программы. Сидишь, читаешь
> анекдоты в Notepad, в это время начальник удаляет у тебя
> соответствующий файл. В идеале, Notepad должен написать
> "Файл был удален пользователем "Big Boss" с комментарием
> "Живо работать!" :)
>

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

sniknik © (10.01.12 14:48) [163]

Он его взял из файловой системы. Из нее и автоприлетит уведомление об удалении файла. Кстати, Notepad++ замечает, что файл был удален и спрашивает, продолжить ли его просмотр или закрыть...

Ega23 © (10.01.12 14:51) [164]

Значит, твоя аналогия неверна...

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

> Кстати, Notepad++ замечает, что файл был удален и спрашивает, продолжить ли его просмотр или закрыть...
локально? а если из сети открыть?

> Кстати, Notepad++ замечает, что файл был удален и спрашивает,
> продолжить ли его просмотр или закрыть...

Вопрос: когда он это замечает?

Вообще предлагаю закончить спор следующим: лучше иметь программу, которая позволяет пользователю настроить автообновление. Потому как программа, которая этого не позволяет, получается из первой путем chAutoRefresh.visible := false и chAutoRefresh.checked := false :)

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

Не надо подменять понятия "автонажимание на Refresh" и обновление по событию.
Это совершенно разные вещи.

sniknik © (10.01.12 15:03) [166]

Так я ж и говорю - смотрим ТЗ и делаем, что там написано.

sniknik © (10.01.12 15:04) [167]

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

Ega23 © (10.01.12 15:04) [168]

При переключении (Application.onActivate) на него точно делает. Когда еще делает, не знаю, потому как для удаления файла я должен deactivate notepad++, а потом срабатывает onActivate и см. выше...

sniknik © (10.01.12 15:07) [170]

Оповещение выскакивает только в том случае, если notepad++ является активным приложением.

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

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

> Вообще предлагаю закончить спор следующим: лучше иметь программу, ...
которая которая работает правильно вопреки желаниям клиента... и если автообновление не нужно/лишнее/в разрез логике, а клиент тем не менее "хочет", то нафиг такого клиента! и это не шутка, проще послать "замудрого" клиента насмотревшегося фантастики в детективах, чем после терять из-за него деньги.

> До этого он как висел на другом мониторе (в моём случае), так и висел, хоть всё поудаляй а потом насоздавай заново но уже с другим содержимым.
так это не автоапдейт, это событийный, т.е. типа закончили редактировать документ, сохранили и по нему обновляется список заголовков документов. это ВЕЗДЕ есть.

> Когда еще делает, не знаю, потому как для удаления файла
> я должен deactivate notepad++, а потом срабатывает onActivate
> и см. выше...
>

Ну вот тебе простой код:
unit Unit31; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ExtCtrls, StdCtrls; type TForm31 = class(TForm) Timer1: TTimer; Label1: TLabel; Button1: TButton; procedure Timer1Timer(Sender: TObject); procedure Button1Click(Sender: TObject); private { Private declarations } public { Public declarations } end; var Form31: TForm31; implementation {$R *.dfm} procedure TForm31.Button1Click(Sender: TObject); begin Timer1.Enabled := True; end; procedure TForm31.Timer1Timer(Sender: TObject); begin Timer1.Enabled := False; if DeleteFile("E:\1.txt") then Label1.Caption := "OK" else Label1.Caption := "Fail"; end; end.

Очень показательно твоё "автообновление".

Ega23 © (10.01.12 15:17) [178]

Это к чему? Я уже 3 раза писал, что всё определеятся пожеланиями заказчика. Веришь, что есть способ реализовать автообновление notepad++ таким образом, чтобы он не требовал onActivate для оповещения?

ЗЫ. У меня на компе давно нет Delphi. Точнее, на этом и не было никогда.

> Веришь, что есть способ реализовать автообновление notepad++
> таким образом, чтобы он не требовал onActivate для оповещения?

Верю. Есть. Но почему-то признано разработчиками не нужным.
Можно (и более того - нужно!) следующее "автообновление" сделать:
1. Перед редактированием записи вытаскиваем самые актуальные данные по ней на данный момент.
2. После изменения записи (успешного, неуспешного - без разницы) - обновление общей выборки.
3. При активации окна - соответственно.
4. Ну и кнопка "Обновить" в целом.
А вот по таймеру... Лично я - категорически против.

Ega23 © (10.01.12 16:00) [180]

Нет у меня таймера. И notepad++ он тоже не нужен. Я и сам против таймеров (за редким исключением)

← →
знайка (2012-01-10 16:23) [182]

> А вот по таймеру... Лично я - категорически против.

А что с таймером не так?

> А что с таймером не так?

Лишняя нагрузка на сервер.

> vuk (10.01.2012 11:27:52) [112]

И если увидит то где, допустим была 10 позиция, три записи до были удалены и
одна вставлена.

> знайка (10.01.2012 13:09:07) [127]

Ну и нафига ты привел, ничего общего с обычной работой, да и строк всего
восемь, а не 400 000
И всеравно неприятно смотреть на эту свистопляску

> Ega23 (10.01.2012 14:33:38) [158]

Более того, ты можешь устроить пакость, сохранить его снова :-)

> Ega23 (10.01.2012 14:40:41) [161]

> 0, 3 и 7 дискретами

Да это серьезная проблема

> Anatoly Podgoretsky © (10.01.12 23:39) [187]
>
> > 0, 3 и 7 дискретами
>
> Да это серьезная проблема

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

обновление данных при multi-user работе Найти похожие ветки