Кроме предложения привести возможную ситуацию, я еще предлагал подумать насколько это действительно необходимо!

Напоминаю. У нас 2 клиента. Один ввел информацию, другой ее тут же должен увидеть. Причем оба клиента редактируют эти данные. Насколько это необходимо в приведенных ситуациях?

Цитата:

1. Охрана - вьезд, выезд автомобиля (+ квитирование событий ), тоже самое (в меньшей степени) взвешивание транспорта

Одна и та же машина одновременно въезжает / выезжает из нескольких ворот? Взвешивается на нескольких весах? Иначе откуда возьмутся 2 клиента?

Цитата:

2. Всякого рода табло - готовность чего-нибудь

Табло - это штука только для просмотра! Здесь вообще интерактив с клиентом не предусматривается. "Лопай что дают".

Цитата:

3. Оперативные остатки - прием заказов (потенциальное кол-во для заказов)

Ну, это теоретически ближе к делу. Но! Я уже описал в предыдущем посте, что это практически бессмысленное занятие. Превышение резерва должно контролироваться на уровне триггеров! Да и потом, что это за организация такая, которая не может обеспечить достаточного резерва, чтобы 2 заказчика не толкались локтями из-за остатка. Правда, к собственно программированию это уже не относится.

Цитата:

4. Централизованный контроль тех. процессов - операторские станции (но это уже "изврат", поскольку существуют SCADA системы)

Эта штука опять-таки, скорее для просмотра. Т.е. мало чем отличается от табло. Вмешательство клиента возможно, но здесь - это особая (исключительная) ситуация. В смысле правка клиентом - исключение.

Цитата:

PS это не в качестве полемики, а так для инф-ии, что такие задачи существуют, я не сомневаюсь, что это известно.

Конечно, существуют. Но! Всегда есть большое "НО". Как минимум, надо уточнить у автора, насколько это необходимо в его конкретной задаче. Как-то я сильно сомневаюсь, что это ему действительно надо. Пока идет треп на тему "А вот хорошо бы еще в нашем самолете предусмотреть бассейн с вышкой. Вдруг мне захочется поплавать". На вопрос "Зачем?" идет ответ "Хочется!"

Так в качестве флейма.

Цитата:

Одна и та же машина одновременно въезжает / выезжает из нескольких ворот?

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

Табло пропускаем - не в тему

Цитата:

Цитата:

3. Оперативные остатки - прием заказов (потенциальное кол-во для заказов)

Ну, это теоретически ближе к делу. Но! Я уже описал в предыдущем посте, что это практически бессмысленное занятие. Превышение резерва должно контролироваться на уровне триггеров! Да и потом, что это за организация такая, которая не может обеспечить достаточного резерва, чтобы 2 заказчика не толкались локтями из-за остатка. Правда, к собственно программированию это уже не относится.

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

По поводу организации - производство скоропортящуйся продукции - возьмем например хлеб, ВЧЕРАШНИЙ хлеб, СЕГОДНЯ уже никому не нужен (ни магазину , ни покупателю - действительно существует страховой запас, но он должен уити, в противном случае получатся убытки, причем такая стратегия д.б. для любого производителя - ну что бы избавиться от "омертвления" оборотных средств, есть правда и исключения)

По поводу отношения к программированию - даже не знаю относиться или нет, на мой взгляд относиться ПО должно решить поставленную задачу.

SCADA - пропускаем, поскольку это уж сильно специфическая задача.

Цитата:

Пока идет треп

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

Господа! Существует великое множество задач помимо бухгалтерских, где нужен VFP!
Поэтому не судите узко!

Владимир Максимов
Сидит пользователь, задумчиво смотри в монитор, чай пьет, птички поют И вдруг, у него на экране начинают происходить какие-то изменения в данных! Кошмар! Кто посмел! Вирус завелся!

Если я лишу своих пользователей автоматического обновления - можно смело считать убытки.
Мед.предприятие - в регистратуре сидит администратор - выписывает талоны посещения на каждого пациента к каждому врачу. Пациент идет к врачу. Делается отметка об уходе пациента из регистратуры.
Врач должен знать - пациент пошел к нему в кабинет. И в этот момент медсестра должна выйти и встретить пациента.
А если она будет мечтать и не нажмет кнопку ОБНОВИТЬ - то она будет мечтать уже в другом месте. Пациент не должен ждать!
Далее. Пациент выходит из кабинета врача и направляется к выходу. Врач делает отметку - пациент вышел.
Кассир, сидящий в другом месте должен знать - Пупкин вышел и идет к нему рассчитываться за лечение.
Если от личного желания кассира будет зависеть: нажать кнопку обновления или нет - то кассир может решить что вышедший человек - сопровождающий или др... и соответственно не взять с него деньги.
Вычитать будут с кого ?c меня или кассира?
В режиме ожидания на экране отражаются занятые кабинеты, и длительность пребывания пациента в кабинете (если он не вышел). Так чтобы менеджер зашедший в регистратуру мог оценить степень загруженности клиники, и не приходится ли пациенту ждать врача, хотя у него сейчас пациента нет.
В таких ситуациях без принудительного обновления основного экрана не обойтись..
Конечно, если человек в текущий момент времени работает только с одним типом документов и не занимается разруливанием ситуаций то принудительное обновление его раздражает.

А помоему Наталья Вы неправильно поняли. Возможно речь идет о моменте редактирования данных. Те в момент когда медсестра указывает что пользователь ушел (те начало редактирования данных) нужно ли обновлть днные? Помоему нет. Вот об этом то и речь ИМХО.

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

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

Цитата:

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

Как это выглядит в Вашем случае? Медсестра должна непрерывно смотреть на монитор, чтобы не прозевать когда там появиться некая отметка? Как эта отметка выглядит? Чисто технически? Неужели новая строка Grid? А если медсестра в это время смотрела другую часть программы? Или вообще не смотрела на монитор? А как медсестра узнает этого самого Пупкина? Посылается фотография?

Цитата:

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

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

Бессмысленно пытаться решить программными средствами задачу, которая программными средствами не решается! Пациент должен сам, по "доброй воле" объявиться. Заявить о своем желании расплатиться. Далее кассир "нажмет кнопку" и уточнит, сколько он должен.

Задача "установления личности" описанным Вами способом в принципе не разрешима. Да и никакими программными средствами Вы не сможете заставить пациента расплатиться.

Цитата:

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

Это задача мониторинга. К описываемой проблеме вообще отношения не имеет. Задача ведь ставилась как "непрерывное обновление" + редактирование.

Причем для случая "менеджер зашедший в регистратуру мог оценить" вполне логичным решением является именно "нажал кнопку". С какой стати на мониторе должна быть постоянная картинка загрузки кабинетов? Регистратору заняться больше нечем? И кстати, что это за менеджер такой, который на основе одной картинки в данный момент времени делает далеко идущие выводы?

Цитата:

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

Вот именно! Именно это и было заявлено как решаемая задача! Я пытался показать не просто бессмысленность, но и откровенный вред подобной реализации!

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

Пофлеймим еще немного

Цитата:

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

С такой задачей не сталкивался, но "здравый смысл" возмущается ;)
Машины едут непрерывным потоком и приемо-сдадчик не может голову оторвать от монитора? У него на мониторе всегда только один единственный список, с которым он и работает? А если въехало десяток машин и ему надо установить указатель на первую, но тут въехало еще парочка и список "поехал" вверх приемо-сдатчик не обложит того особо умного программиста?

По поводу резерва даже цитату выдрать не получается. Общая идея понятна, но изложение хромает

Если я правильно понял, то речь шла о регистрации физической отгрузки. Когда отгрузка не по предварительным заявкам (тут можно и откатить заказ, если отказ триггера), а прямой физический отпуск товара. Но! Это задача не выписки предварительных документов, а регистрация факта. Это принципиально другая задача. Здесь на физический остаток вообще не смотрят. Что физически отгрузили, то и обязаны зарегистрировать. Даже если отгрузили больше чем физически есть. Это предмет последующих разборок кладовщиков, начальства и программиста.

Цитата:

По поводу отношения к программированию - даже не знаю относиться или нет, на мой взгляд относиться ПО должно решить поставленную задачу.

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

Цитата:

Пофлеймим еще немного

С большим удовольствием.

Цитата:

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

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

Цитата:

У него на мониторе всегда только один единственный список, с которым он и работает?

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

Цитата:

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

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

Цитата:

По поводу резерва даже цитату выдрать не получается. Общая идея понятна, но изложение хромает

Да, ладно - пишу как понимаю сам, но такт оценил, в оценке эпистолярного жанра

Цитата:

Если я правильно понял, то речь шла о регистрации физической отгрузки. Когда отгрузка не по предварительным заявкам (тут можно и откатить заказ, если отказ триггера), а прямой физический отпуск товара. Но! Это задача не выписки предварительных документов, а регистрация факта. Это принципиально другая задача.

Согласен, согласен.

Цитата:

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

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

Цитата:

Бардак в принципе невозможно формализовать.

Как у Спилберга в "Парке Юрского периода" - "Хаос , подчиняется своим законам", здесь ,наверное, имеет смысл говорить об инвариантности алгоритмов в зависимости от начальных и граничных условий.

Hi, PaulWist & All!

Есть просто ДРУГОЙ ПОДХОД к проблемам оперативной передачи информации - на
основе информационных сообщений.

Т.е. не надо рефрешить массив данных каждую минуту - надо создать систему
рассылки и приёма сообщений, и тогда изменение "остатка товара", "появление
пациента" и вообще всякое прочее изменение состояния будет
сопровождаться выдачей сообщения в системе - и соответственно отображением
этого сообщения на экране у заинтересованных "клиентов"... Заодно решается
вопрос по "узнаванию" сообщения - ну добавилась строка в гриде из 1000
строк - и как просто её найти будет?Или тем хуже - изменилась! Было
12345678 а стало 12345567 - я посмотрел бы на того пользователя, который
сможет в многострочном гриде визуально отследить такое изменение

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

2Петров Андрей

Цитата:

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

Ну тут проблем нет - ведь не в гриде же редактировать данные...

2Владимир Максимов

Цитата:

Медсестра должна непрерывно смотреть на монитор, чтобы не прозевать когда там появиться некая отметка? Как эта отметка выглядит? Чисто технически? Неужели новая строка Grid?

Звук+ новая строка в гриде.

Цитата:

как медсестра узнает этого самого Пупкина?

Ну это всеж таки не проспект. Если идет более одного человека медсестра может спросить человека и т.д. У него в руках карта посещения...

Цитата:

Пациент должен сам, по "доброй воле" объявиться. Заявить о своем желании расплатиться.

Безусловно. Но человек после посещения врача может испытывать стресс и т.д.

Цитата:

Далее кассир "нажмет кнопку" и уточнит, сколько он должен.

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

Цитата:

Да и никакими программными средствами Вы не сможете заставить пациента расплатиться.

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

Цитата:

Задача ведь ставилась как "непрерывное обновление" + редактирование.

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

Цитата:

опустошаю RowSource GRIDa

Это ведь не редактирую...

Цитата:

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

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

Цитата:

И кстати, что это за менеджер такой

А кто его знает...
Я именно к тому и клоню, что жизнь может ставить разные задачи, а люди разные вопросы.
Наверно ведь у летного диспетчера должны появлятся самолеты сами по себе, а не когда он нажмет кнопку обновить...
И моя дочь, которая готовится к тестам по экономике уже совершенно точно знает :
если в задаваемом вопросе содержится слово ВСЕГДА ли при таких то и при сяких то условиях происходит то или то , то надо отвечать - НЕТ...
потому что не всегда...