АвтоОбновление

← →
Bacuc © (2004-07-21 18:14) [0]

С базой работают три приложения по сети...
Что нужно сделать, чтобы:
при изменении базы приложением №1 в приложении №2 автоматически обновился DBGrid?

← →
Соловьев © (2004-07-21 18:14) [1]

1. СУБД?
2. Бегаешь быстро? :)

← →
Reindeer Moss Eater © (2004-07-21 18:18) [2]

Что нужно сделать, чтобы:
при изменении базы приложением №1 в приложении №2 автоматически обновился DBGrid?

Известно что.
DataSet.Close;
DataSet.Open;

← →
Соловьев © (2004-07-21 18:20) [3]

> Известно что.
> DataSet.Close;
> DataSet.Open;

упустил главное - аттоматический код:)

И еще не ясно - может транзакции надо будет переоткрыть. Чего тут гадать - автор не ответил на п.1 :)

← →
Reindeer Moss Eater © (2004-07-21 18:25) [4]

упустил главное - аттоматический код:)

А что такое автоматический код?
Это код вставляемый IDE автоматически?

PS чё спрашивали, на то и ответил.

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

← →
Reindeer Moss Eater © (2004-07-21 18:25) [5]

Ответ кстати тот же самый будет.

← →
Соловьев © (2004-07-21 18:28) [6]

> при изменении базы приложением №1 в приложении №2 автоматически
> обновился DBGrid?

т.е. есть какая-то коллбек функция, или ивент(как в ИБ) который АВТОМАТИЧЕСКИ(т.е. без каких либо телодвижений - нажатий на кнопки и т.п.) обновит НД.

> Ответ кстати тот же самый будет.

будет, но с существенными дополнениями :)

← →
Reindeer Moss Eater © (2004-07-21 18:30) [7]

А у меня в ответе кнопки и телодвижения есть?

← →
Bacuc © (2004-07-21 18:55) [8]

> Соловьев © (21.07.04 18:14) [1]
> 1. СУБД?
> 2. Бегаешь быстро? :)

1. MySQL
2. Возможно ;)

← →
Anatoly Podgoretsky © (2004-07-21 23:55) [9]

Жалко только пользователей приложения №2

← →
Bacuc © (2004-07-22 03:52) [10]

> Anatoly Podgoretsky © (21.07.04 23:55) [9]

то есть?

← →
Ильш © (2004-07-22 07:16) [11]

а еще есть поиск по форуму !!!!!!!!!!!!!!!!!!!!!!!
ты не первый

← →
Соловьев © (2004-07-22 09:35) [12]

> А у меня в ответе кнопки и телодвижения есть?

подразумевается

> 2. Возможно ;)

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

← →
Draught © (2004-07-22 10:32) [13]

вариант такой:
если база не сильно большая, ну что бы сетку сильно не грузить, а то ведь обновление таскает туда-сюда всю базу, то можно автоматическое обновление поставить через какой-нить интервал времени, что-нить типа Table.refresh. Беду с юзверями, у которых во время ввода обновилась информация решить можно очень просто, а самое главное это будет правильно: клиент копит у себя информацию до какой-нить контрольной точки, например этой точкой может быть нажатие на кнопочку "ВЫПИСАТЬ", т.е. символизируется выписывание счета, В этот момент транзакция, которая соберет, все, что накопил клиент и бросит на сервер... таким образом у юзверя хоть 10 раз все обновится, все, что он занес у себя он не потеряет... Бегать не придется

← →
Draught © (2004-07-22 10:33) [14]

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

← →
Соловьев © (2004-07-22 10:35) [15]

> В этот момент транзакция, которая соберет, все, что накопил
> клиент и бросит на сервер...

это називается не транзакция , а кешированные изменения.

← →
Bacuc © (2004-07-22 15:49) [16]

> вариант такой:
> если база не сильно большая, ну что бы сетку сильно не грузить,
> а то ведь обновление таскает туда-сюда всю базу, то можно
> автоматическое обновление поставить через какой-нить интервал
> времени, что-нить типа Table.refresh. Беду с юзверями, у
> которых во время ввода обновилась информация решить можно
> очень просто, а самое главное это будет правильно: клиент
> копит у себя информацию до какой-нить контрольной точки,
> например этой точкой может быть нажатие на кнопочку "ВЫПИСАТЬ",
> т.е. символизируется выписывание счета, В этот момент транзакция,
> которая соберет, все, что накопил клиент и бросит на сервер...
> таким образом у юзверя хоть 10 раз все обновится, все, что
> он занес у себя он не потеряет... Бегать не придется

Сидят два оператора БД, скорость их работы и скорость обновления базы имеет большое значение... Что получается? Первый оператор добавляет запись в базу, а второй ее не увидит, даже если нажмет кнопку "Рефреш"... Придется ждать пока первый изменения не запостит :( Не, не подходит :(
> Ильш © (22.07.04 07:16) [11]
> а еще есть поиск по форуму !!!!!!!!!!!!!!!!!!!!!!!
> ты не первый

Ну скинь тогда ссылку где это уже обсуждалось...

← →
VAleksey © (2004-07-22 16:25) [17]

Зачем пользователю (а) нужно видеть то что сделал пользователь (б) оператор?

← →
Sergey13 © (2004-07-22 17:26) [18]

2Bacuc © (22.07.04 15:49) [16]
А у меня в огороде бузина, а в Киеве дядька. И пока бузина не поспеет, дядька ее не ест. 8-)
>Придется ждать пока первый изменения не запостит :( Не, не подходит :(
А если он не запостит ее? Тогда как? Второй ее уже видел и ...
Плюнь короче. Это проблема не в базе или работе, это проблема у тебя в голове. Пошукай поиском - дофига найдешь.

← →
Соловьев © (2004-07-22 17:28) [19]

> скорость их работы и скорость обновления базы имеет большое
> значение...

это слежение за атомным реактором или что?

← →
Draught © (2004-07-22 17:29) [20]

> Сидят два оператора БД, скорость их работы и скорость обновления
> базы имеет большое значение... Что получается? Первый оператор
> добавляет запись в базу, а второй ее не увидит, даже если
> нажмет кнопку "Рефреш"... Придется ждать пока первый изменения
> не запостит :( Не, не подходит :(

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

> это називается не транзакция , а кешированные изменения.

ну да, так и есть... тока это можно делать с использованием кэширования, а можно писать большой SQL запрос, который будет вначале с BEGIN TRAN, затем текст запроса, а в конце либо с COMMIT, либо ROLLBACK в зависимости от действий пользователя... соответственно выполняться будет целиком, потерь, я думаю, вов ремя работы не будет...

← →
Соловьев © (2004-07-22 17:32) [21]

>
> ну да, так и есть... тока это можно делать с использованием
> кэширования, а можно писать большой SQL запрос, который
> будет вначале с BEGIN TRAN, затем текст запроса, а в конце
> либо с COMMIT, либо ROLLBACK в зависимости от действий пользователя...
> соответственно выполняться будет целиком, потерь, я думаю,
> вов ремя работы не будет...

Такие длинные транзакции приведут к тому,что работать с БД будет только один человек.

← →
Draught © (2004-07-22 17:41) [22]

> Такие длинные транзакции приведут к тому,что работать с
> БД будет только один человек.

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

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

← →
Sergey13 © (2004-07-22 17:47) [23]

2Draught © (22.07.04 17:41) [22]
Странными терминами вы оперируете молодой человек. Бланки с блокируемыми номерами. Кучи бланков... 8-)

← →
bushmen © (2004-07-22 17:49) [24]

> Если выбираешь кучу номеров, то можно заблокировать на время
> весь столбец...

А причем тут записи и столбец? Каким образом они связаны?

← →
Draught © (2004-07-22 17:52) [25]

> Sergey13 ©

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

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

> bushmen © (22.07.04 17:49) [24]
>
> А причем тут записи и столбец? Каким образом они связаны?

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

мне немного непонятен вопрос... :)

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

> А если нет механизма блокировок ?

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

Или другая картина: "сидит клиент, общается с менеджером, спрашивает: "У вас есть болтик?" - на что менеджер, посмотрев в БД говорит: "ЕСТЬ!" - но он не выписывает со склада болтик, т.к. клиент может передумать, нужно дождаться когда клиент заплатит денежку, клиент платит денежку, менеджер пытается выписать со склада болтик, а его там уже нету, его уже кто-то выписал!"
Здесь же клиент не останется без болтика, т.к. менеджер его посмотрев заблокирует и уже другой не сможет его увести у клиента.

Вообщем ответ такой: Механизм блокировок должен быть! Иначе все накроется медным тазом при работе по сети...

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

>Draught ©

См. первую часть (до смайла) поста № [27]
:)
Вставлю лишь "... и считающий, что на основании безосновательных глубокомысленных, не подкрепленными знаниями, рассуждений, ..."

2Draught © (22.07.04 18:19) [28]
>Вообщем ответ такой: Механизм блокировок должен быть!
Нет! Ответ другой. Думать надо при проектировании базы и вообще при работе. Есть например понятие - исключительная ситуация. Его еще обрабатывать можно при желании.
>Иначе все накроется медным тазом при работе по сети...
Даже не по сети... 8-)

Про менеджеров-болтиков. А если другой манагер выписывает таки счет какому нибудь лабуху. А ему - погди, мил человек, другой манагер заблокировал болтики. 8-)

> Johnmen ©

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

Правильно и учитывать когда и где ставить блокировку, а когда можно не ставить и обрабатывать исключительную ситуацию...
> :)
> А если нет механизма блокировок ?

Я правильно вставил??? Я вообще ничего не понял... предложение не закончено...

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

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

> Думать надо при проектировании базы и вообще при работе.
> Есть например понятие - исключительная ситуация. Его еще
> обрабатывать можно при желании.

2Draught © (23.07.04 08:28) [31]
>В такой ситуации обычно говорят...
Клиенты в такой ситуации обычно говорят - больше я к вам ни ногой. Тем более, если он набирал покупку из 100 разных болтиков и 200 гаечек. В такой ситуации только выйдя на работу в воскресение можно сформировать заказ. 8-)

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

Это круто и наукообразно.

Draught © (22.07.04 18:19) [28]
Здесь же клиент не останется без болтика, т.к. менеджер его посмотрев заблокирует и уже другой не сможет его увести у клиента.

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

Вообщем ответ такой: Механизм блокировок должен быть! Иначе все накроется медным тазом при работе по сети...

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

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

> Anatoly Podgoretsky ©

хорошо, я учту это...

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

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

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

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

АвтоОбновление Найти похожие ветки