Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

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

Страницы: 1 2 >
Bacuc © (2004-07-21 18:14:00)
С базой работают три приложения по сети...
Что нужно сделать, чтобы:
при изменении базы приложением №1 в приложении №2 автоматически обновился DBGrid?

Draught (2004-07-23 09:49:00) [1]

> Anatoly Podgoretsky ©

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

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

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

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

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

Anatoly Podgoretsky (2004-07-23 09:22:00) [2]
И не списывай свой непрофессионализм какими то высокими материями и абсурдными утверждениями о базах. Лучше наймите на работу программиста и разработчика баз данных, вам же дешевле будет.

Anatoly Podgoretsky (2004-07-23 09:20:00) [3]
Draught © (22.07.04 18:19) [28]
Здесь же клиент не останется без болтика, т.к. менеджер его посмотрев заблокирует и уже другой не сможет его увести у клиента.

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

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

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

TohaNik (2004-07-23 09:13:00) [4]
>Значит получится картина очень простая: "человек переводит деньги >в банк, миллион по рублю, сам бежит к ближайшему банкомату, ждет >когда побольше денег накапает, а потом снимает сколько накапало, >но самое интересное, что вконце у него стоит ROLLBACK" - вот что >будет, если не будет механизма блокировок.

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

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

Draught (2004-07-23 08:28:00) [6]

> Johnmen ©

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

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

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

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

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

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

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

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

Johnmen (2004-07-22 18:29:00) [8]
>Draught ©

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

Draught (2004-07-22 18:19:00) [9]

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

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

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

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

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

Johnmen (2004-07-22 18:01:00) [10]
Вот что меня всегда умиляет, так это когда человек, даже терминологией не очень владеющей, пытается давать наукообразные советы и разводить предметную философию...
:)
А если нет механизма блокировок ?

Draught (2004-07-22 17:55:00) [11]

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

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

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

Draught (2004-07-22 17:52:00) [12]

> Sergey13 ©

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

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

bushmen (2004-07-22 17:49:00) [13]
> Если выбираешь кучу номеров, то можно заблокировать на время
> весь столбец...

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

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

Draught (2004-07-22 17:41:00) [15]

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

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

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

Соловьев (2004-07-22 17:32:00) [16]

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

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

Draught (2004-07-22 17:29:00) [17]

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

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

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

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

Соловьев (2004-07-22 17:28:00) [18]

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

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

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

VAleksey (2004-07-22 16:25:00) [20]
Зачем пользователю (а) нужно видеть то что сделал пользователь (б) оператор?

Страницы: 1 2 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »