Отслеживание изменений другим пользователем

← →
AlexSt © (2006-11-17 11:03) [0]

Подскажите, кто знает. Есть ли возможность отследить изменения сделанные другим пользователем без переодического Requery.
База - mdb (MS Access)
Подключение через компоненты ADO

← →
Sergey13 © (2006-11-17 11:08) [1]

Нет. Да и не нужно это в 99% случаев.

← →
AlexSt © (2006-11-17 11:14) [2]

Жаль!

← →
k2 © (2006-11-17 11:17) [3]

to AlexSt © а зачем?

← →
AlexSt © (2006-11-17 11:28) [4]

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

← →
k2 © (2006-11-17 11:34) [5]

AlexSt © (17.11.06 11:28) [4]
откуда то девочки взялись
полнее опиши задачу

← →
AlexSt © (2006-11-17 11:49) [6]

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

← →
k2 © (2006-11-17 11:57) [7]

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

← →
AlexSt © (2006-11-17 12:05) [8]

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

← →
k2 © (2006-11-17 12:09) [9]

AlexSt © (17.11.06 12:05) [8]
не думаю што стоит периодочески, кнопки "обновить" достаточно
пока пациента выслушиваем - нажали

← →
Anatoly Podgoretsky © (2006-11-17 12:10) [10]

> AlexSt (17.11.2006 11:28:04) [4]

> и на одно и тоже время небыло записано два человека.

Ввести понятие уникальность в базу.

← →
Anatoly Podgoretsky © (2006-11-17 12:11) [11]

> k2 (17.11.2006 11:34:05) [5]

> откуда то девочки взялись

Не известно откуда, но понятно зачем.

← →
Anatoly Podgoretsky © (2006-11-17 12:12) [12]

> AlexSt (17.11.2006 11:49:06) [6]

> доктор, пациент, время приема

По этим полям уникальный индекс.

← →
k2 © (2006-11-17 12:14) [13]

Anatoly Podgoretsky © (17.11.06 12:12) [12]
а доктор+(дата)время разве недостаточно уникально?
я просто с аксесс мягко говоря давно и неправда

← →
AlexSt © (2006-11-17 12:27) [14]

> Ввести понятие уникальность в базу.

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

> кнопки "обновить" достаточно
> пока пациента выслушиваем - нажали

Попробуем, будут возмущаться, придумаю что нибудь другое.

← →
k2 © (2006-11-17 12:30) [15]

> AlexSt © (17.11.06 12:27) [14]
>
>
> на дату/время ставить уникальность не буду, тем более, что
> иногда возможна запись двух пациентов на одно время.

ээ так нельзя - или возможна или невозможна

← →
AlexSt © (2006-11-17 12:33) [16]

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

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

← →
AlexSt © (2006-11-17 12:35) [17]

> ээ так нельзя - или возможна или невозможна

специфика работы, пока одного по аппаратам гоняют, другого доктор смотрит, а если много напишут и пациенты поднимут скандал по голове получат все.

← →
k2 © (2006-11-17 12:42) [18]

обновление тебе нужно штобы предотвратить запись двух пациентов на одно время, или больше двух? или больше трех?

← →
AlexSt © (2006-11-17 12:45) [19]

По усмотрению регистратуры

← →
k2 © (2006-11-17 12:48) [20]

ну и тогда сделать дату со временем до минут, чаще одного пациента в минуту врядли регистратура усмотрит, будет и уникальность по времени
хотя у вас коммерческая :)

← →
AlexSt © (2006-11-17 12:50) [21]

Отож! Что они завтра придумают одному Богу известно.

← →
Sergey13 © (2006-11-17 12:58) [22]

> [21] AlexSt © (17.11.06 12:50)

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

← →
ЮЮ © (2006-11-17 12:59) [23]

Как будто пациенты в десяти очередях со скоростью 1 чел в минуту записываются к одному и тому же доктору.

- Вы к кому? на какое время?
обновился запрос. Видны окна. Что-то кликнул. Записал "без пациента"
запрос обновился. Если кто-то перекся, клиент(программа) ругнулась. Оператор или оставил на то же время (вариант по двое, один аппараты ...) или выбрал другое время... Проставил имя пациента.

Или начинать с имению Вы Кто? Открыл карточку. Далее с начала.

← →
Anatoly Podgoretsky © (2006-11-17 13:07) [24]

> k2 (17.11.2006 12:14:13) [13]

Достаточно уникально, поскольку соответствуе условию задачи, поэтому только два этих поля и выделены жирным. Отдельно доктор и дата недостаточно, а пациент вообще не нужен.
Поэтому уникальный индекс по этим полям, а предложение проверять эти два поля не выдерживает критики, на момент вставки состояние возможно будет уже другое. Дата конечно должна подчиняться каким то правилам, обычно минуты = 0, 15, 30, 45 или аналогично
По крайней мере мой визуальный анализ работы регистратур показывает определенный закон во времени приема. Сейчас например они ручками в книгу пишут.

← →
Anatoly Podgoretsky © (2006-11-17 13:08) [25]

> AlexSt (17.11.2006 12:27:14) [14]

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

Противоречит оглашеным условиям задачи.

← →
Anatoly Podgoretsky © (2006-11-17 13:09) [26]

> k2 (17.11.2006 12:30:15) [15]

Все возможно если за основу взять невероятностную математику
Хайчкикер по галактике.

> AlexSt (17.11.2006 12:35:17) [17]

Это уже новая сущность, количество пациентов на одно время, требуется дополнительное поле и еще одно ограничение, N <= M

> k2 (17.11.2006 12:42:18) [18]

Левая рука не знает, что делает правая, а потом Чернобылям удивляемся.

> k2 (17.11.2006 12:48:20) [20]

> хотя у вас коммерческая :)

А, тогда все понятно, можно и сто написать на одно время

> Sergey13 (17.11.2006 12:58:22) [22]

В двойном размере.

> Anatoly Podgoretsky © (17.11.06 13:07) [24]
> > k2 (17.11.2006 12:14:13) [13]
>
> Достаточно уникально, поскольку соответствуе условию задачи,
> поэтому только два этих поля и выделены жирным. Отдельно
> доктор и дата недостаточно, а пациент вообще не нужен.
> Поэтому уникальный индекс по этим полям, а предложение проверять
> эти два поля не выдерживает критики, на момент вставки состояние
> возможно будет уже другое.

select for update нет в аксессе?

> ЮЮ (17.11.2006 12:59:23) [23]

Правильно мыслишь, нужен профессиональный подход, анализ задачи, постановка, разработка алгоритмов, базы, скриптов, процедур и только потом Дельфи.
А не тяп, ляп, сейчас слева один тяп, потом справа другой ляп и глядишь операторый уже плачут. За последнее время ГИС продемонстрировали это в всей красе.

> k2 (17.11.2006 13:14:31) [31]

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

> k2 (17.11.2006 13:18:34) [34]

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

← →
SlymRO (2006-11-20 04:22) [36]

Бродкаст UDP рассылать нотификацию Изменения и на нее Рекверить

← →
Umnik (2006-11-20 11:11) [37]

AlexSt ©
Перед сохранением нужно проверять есть ли в ближайшее время от внесенного времени к этому врачу кто-то и сообщать
Типа:
"Последний паиент на 10-15 вы действительно хотите добавить пациента на 10-16?"

Отслеживание изменений другим пользователем Найти похожие ветки