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

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

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

Совместное использование одной таблицы [MSSQL]

Страницы: < 1 2 3 4 5 6 >
DeadMeat © (2006-11-20 16:57:00)
Здравствуйте.
Я в базах новичек, поэтому сильно не бейте (хотя бы не ногами).
Есть:

СУБД Microsoft SQL 2000 (SP3)
ADO (компоненты ADOConnection и ADODataSet)
EhLib (компоненты MemTableEh и DBGridEh)
Таблица (просто список людей)
Несколько пользователей (работники)

Надо:

При совместной работе с одной таблицей двух и более пользователей разруливать ситуацию с обновлением информации.

Понимаю, что сказал бред. Попробую пояснить.
Допустим пользователь ЮЗЕР1 выбрал первую запись для редактирования (первая - это образно, первая сверху). Отредактировал и сохранил обратно в базу (MemTableEh.Edit, MemTableEh.Post, MemTableEh.ApplyUpdates(0)). Если после этого пользователь ЮЗЕР2 решит отредактировать эту же запись, то выскочит ошибка "Не удается найти строку для обновления.......". Погуглив выяснилось, что проблема в том, что после редактирования найти эту запись ЮЗЕР2 уже не может, т.к. критерии поиска уже другие. Соответственно
введя первичный ключ и добавив в AfterOpen задание параметра Update Criteria значением adCriteriaKey проблема решается. Но лишь проблема появления ошибки. Т.е. получается, что ЮЗЕР2 не видя то, что записал в базу ЮЗЕР1 запишет туда что-нить свое. А вот хотелось бы отобразить изменения, которые сделал ЮЗЕР1 для всех остальных пользователей. Вводить дополнительно сетевую часть (передавать всем броадкастом информацию об обновлениях) не очень хочется. Каждый раз делать Requery перед редактированием любой записи тоже. Может есть способ еще? Как определить, что "вот эту"запись изменили, и что "вот эту"запись надо обновить? Пробовал проверять RecordStatus на rsModified - не помогло.

ЗЫ. Вполне вероятно, что гдето написал бред, но я только начал эту область осваивать.

ЗЗЫЫ. Пишу в BDS2006.

ANB (2006-11-23 14:15:00) [61]

> например R/2

Во, млин. Я такого не слышал даже - чего это ?

Anatoly Podgoretsky (2006-11-23 14:06:00) [62]
> ANB (23.11.2006 14:01:54) [54]

С этой стороны, я с тобой полностью согласен, но тогда есть еще более масляные куски, например R/2

clickmaker (2006-11-23 14:01:00) [63]

> [50] Anatoly Podgoretsky © (23.11.06 13:43)
> > clickmaker (23.11.2006 13:39:49) [49]
>
> Надо бы сначала разобраться с предметной областью, а то
> мы тут копья ломаем.

да меня возмутил просто наезд г-на MsGuns.
Ничем не обоснованный, кстати. И без любого намека на конструктивизм. Дескать, "я не знаю, как делать, но так - неправильно"

ANB (2006-11-23 14:01:00) [64]

> А может, ну его нафиг этот Оракл, нам пальцы крутить ни
> к чему :)

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

Anatoly Podgoretsky (2006-11-23 13:52:00) [65]
> ANB (23.11.2006 13:48:51) [51]

А может, ну его нафиг этот Оракл, нам пальцы крутить ни к чему :)

ANB (2006-11-23 13:48:00) [66]

> Поэтому хочется как можно более независимых решений

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

ИМХО еще имхестее :) Выкинь на фиг мс скл, поставь оракл и наслаждайся :)

Anatoly Podgoretsky (2006-11-23 13:43:00) [67]
> clickmaker (23.11.2006 13:39:49) [49]

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

clickmaker (2006-11-23 13:39:00) [68]

> [48] Anatoly Podgoretsky © (23.11.06 13:37)
> > ANB © (23.11.06 13:13) [47]
>
> Не пытайся переносить методы и правила Оракла на другие
> базы

вот и я про то же.
Когда я подобную байду делал, у меня был сначала Sybase, а потом MS SQL. Поэтому хочется как можно более независимых решений

Anatoly Podgoretsky (2006-11-23 13:37:00) [69]
> ANB © (23.11.06 13:13) [47]

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

ANB (2006-11-23 13:13:00) [70]

> а как узнать, кто именно взял запись и держит?

+ юзеровая блокировка - туда можно всю инфу класть. а в простейшем случае эта инфа и не нужна.

Anatoly Podgoretsky (2006-11-23 12:45:00) [71]
> ANB (23.11.2006 12:08:43) [43]

> а) не давать редактировать одну запись одновременно двум юзерам

Не давать расходовать в отрицательную сторону. А не про монопольное использование записи.

Anatoly Podgoretsky (2006-11-23 12:12:00) [72]
> clickmaker (23.11.2006 11:49:42) [42]

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

clickmaker (2006-11-23 12:11:00) [73]

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

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

> Это легче и надежнее всего таки на серверных блокировках
> разрулить

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

ANB (2006-11-23 12:08:00) [74]

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

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

clickmaker (2006-11-23 11:49:00) [75]

> [41] Anatoly Podgoretsky © (23.11.06 11:44)
> > clickmaker (23.11.2006 11:30:40) [40]
>
> С трудом разруливается.

в таком случае, не понимаю, чем предложенный мной вариант резервирования хуже?
И что все-таки вы имеете в виду под "резервированием"?

Anatoly Podgoretsky (2006-11-23 11:44:00) [76]
> clickmaker (23.11.2006 11:30:40) [40]

С трудом разруливается.

clickmaker (2006-11-23 11:30:00) [77]

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

а как в данном случае разруливается эта ситуация:

> В случае сваливания клиента/сервера "блокированные" записи
> так такими и остануться

ANB (2006-11-23 11:25:00) [78]

> clickmaker © (23.11.06 11:15) [38]

Переходи на оракл :) В нем проблем с родными серверными блокировками нету - все функции нормально работают, только еще раз заблокировать не даст. Плюс есть еще юзеровые блокировки, вообще гибкая вещь.

clickmaker (2006-11-23 11:15:00) [79]

> [36] Anatoly Podgoretsky © (23.11.06 11:09)
> > clickmaker (23.11.2006 10:35:31) [31]
>
> У блокировок обычный минус - всем хана, даже некоторые аггрегатные
> функции не сможешь выполнить

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

clickmaker (2006-11-23 11:13:00) [80]

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

совершенно верно. Так и делал. У поля есть статусы "свободно", "занято", "продано". И можно узнать, кто конкретно в процессе его продажи находится.
Но меня интересует именно глубинный механизм. Что, есть для этого какие-то встроенные средства SQL? И к тому же не зависящие от СУБД

> пока транзакцию, меняющую это поле на статус "Заблокировано"
> не закоммитишь, никто этой блокированности не увидит. Сие
> может привести к одновременной "Блокировке" двумя и более
> пользователями

для этого есть хинт holdlock

Страницы: < 1 2 3 4 5 6 >

Наверх

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