Мастера 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-24 10:54:00) [41]

> Обновить инфу с сервера.

Сначала обновляешь вместе с блокировкой. И тогда, несмотря на мнение уважаемого Sergey13 © ты можешь быть уверен, что пока юзер чешет репу и пьет чай, глядя на форму редактирования, а потом одним пальцем с длинным ногтем печатаем там изменения - никто эту запись уже не заменит - она блокирована. А если клиентская программа навернется - блокировка снимется сама.

clickmaker (2006-11-24 10:05:00) [42]

> [71] MsGuns © (23.11.06 21:08)

не, ну в упор не понимаю, причем тут транзакция?
У нас есть набор неких объектов (места в зале, список товаров etc).
Мне нужно, что если один человек зарезервировал объект для потенциально длительной операции, другой, с другого рабочего места ДАЖЕ НЕ пытался бы его использовать. А как он может этого не делать, если он не видит текущего статуса объекта? Может попытаться, да, получить отлуп. Но почему бы не упредить его действия? Ведь это лишняя работа, а системы такие, как правило, работают в довольно жестком темпе.
Хорошо, термин "блокировка" я употребил неправильно, потому что он слишком пахнет спецификой СУБД. Ну пусть будет резервирование.
Ну хоть котлету из меня сделайте - не понимаю: каким боком тут транзакции, и в чем именно у меня "непонимание механизма обмена данными в технологии "клиент-сервер"?

Sergey13 (2006-11-24 09:10:00) [43]
> [72] DeadMeat © (24.11.06 09:03)
> Вообщем если я правильно понял, то все проблемы опять сводятся к одной. Обновить инфу с сервера.
Проблема - сделать нормальную реакциюклиентской программы на отлуп сервера по нарушению правил целостности (которые должны быть). Любое обновление теряет актуальность сразупо получении оного. Т.е. снимается только часть (хоть и не малая) проблемы.

Anatoly Podgoretsky (2006-11-24 09:08:00) [44]
> DeadMeat (24.11.2006 09:03:12) [72]

> а почему "Это ничего Вам не даст в плане актуальности этой самой записи" ?

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

DeadMeat (2006-11-24 09:03:00) [45]
Ох.... Не думал, что такой вопрос может вызвать подобный резонанс.
Читаю вас тут с удовольствием. Как я сказал, я новичек, а тут более-менее опыту прибавляется.
Пришел к выводу, что в данном конкретном случае есть два "простых" выхода. Делать подкачку, обновляя только видимую часть записей с запасом (без кеширования) и обновлять запись перед редактированием. Т.е. когда пользователь открыл запись на редактирование, в форме уже обновленная информация (кстати, а почему "Это ничего Вам не даст в плане актуальности этой самой записи" ? [21]). Ну, а второй выход - не делать вообще ничего. Просто не отображать изменения. Это из простых вариантов.
Осталось решить с чуть более сложными.
Резервирование говорите....
Вообщем если я правильно понял, то все проблемы опять сводятся к одной. Обновить инфу с сервера. Следовательно, нужно решить как это сделать более оптимальным способом.

MsGuns (2006-11-23 21:08:00) [46]
>clickmaker © (23.11.06 15:01) [63]
>Вполне рабочий вариант. И он реально работает.

У меня есть несколько систем на парадоксе 3.5 в ДОСе. Все работают до сих пор. И что ?

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

Вы поймите, что Ваша самая основная "консерваторская" ошибка именно в этом магическом слове "блокировка".
И уясните еще одну простую весчь:

НИ ОДИН СЕРВЕР НИКОГДА НИКОГО И НИ О ЧЕМ НЕ ОБЯЗАН УВЕДОМЛЯТЬ.
Ну не для этого он создан ! Это все равно, что если автодорожники задумают ремонт в районе, допустим, Невского, и озадачатся оповестить всехвладельцев авто, гостей города, транзитников, а кроме того всех, кто может в это время проехать по этой части города на общественном или ином транспорте как пассажир.
Просто поставьте себя на место автодорожников и Вам примерно будет понятна логика сервера, которому "до фени" проблемы одного конкретного клиента, как бы "крут" он ни был.
Лично для меня очень большую ясность в этом вопросе в свое время внесли книги Востикова и Ковязина. Хотя там речь идет об Interbase, однако соль клиент-серверного подхода к решению конфликтов в "базовых" проблемах изложена ясно и доступно. Советую Вам почитать. Ключевое слово "транзакция".

>Вот MsGuns пришел и разнес меня.

;) Это разве "разнес" ? Видели бы Вы, какую котлету тут делали из меня аксакалы лет 5 назад, когда я с пеной у рта доказывал всем какие они "дураки", что недооценивают парадокс, дибэйз и т.д. ;)))

>Правда, взамен ничего не предложил.

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

Anatoly Podgoretsky (2006-11-23 16:37:00) [47]
> Jeer (23.11.2006 16:32:08) [68]

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

Anatoly Podgoretsky (2006-11-23 16:36:00) [48]
> Павел Калугин (23.11.2006 15:58:07) [67]

Ну вот, как только назвал это, так я и тоже вспомнил. У них есть и своя БД для него SAP DB
Но они не привязаны а БД, чаще всего используется Оракл.
Так если они такие деньги платят разработчику форм, то сколько же они платят тому кто работает с Оракл в этой системе.

Вот тут уже точно масла для хлеба хватит.

Jeer (2006-11-23 16:32:00) [49]

> Anatoly Podgoretsky © (23.11.06 15:47) [66]

Я в свое время пытался в Сбербанке что-то подобное внедрить.
Сервера Motorola, OC AIX, у клиента только X Terminal под Windows.
Формы выглядят по разному в зависимости от допуска рабочего места.
Безопасность по максимуму:)

Павел Калугин (2006-11-23 15:58:00) [50]
> [66] Anatoly Podgoretsky © (23.11.06 15:47)

это про SAP R3?
ну да, это флаг....

Anatoly Podgoretsky (2006-11-23 15:47:00) [51]
> Jeer (23.11.2006 15:20:05) [65]

Я не про базу R3, а про систему, базу как раз любую можно использовать, да и базу R3 они не так давно разработали. Я работал (как пользователь) с этой системой, сервер расположен в Копенгагене, канал 64/128 кб, печатать можно на любой принтер, хоть в Китае.
На месте только SDK (200 mb) даже формы на сервере. Время реакции типовое 0,5 секунды от запроса до появление формы. Формы кривые, смотреть страшно. Но интересно сделал один запрос одна форма, делаешь запрос повторно, уже другая форма.
Заведение учетной записи 1000 долларов, изменение формы значительно больше. Каждый филиал должен самостоятельно все оплачивать. Оттуда и информация об зарплате.

Jeer (2006-11-23 15:20:00) [52]
R3 у Ingres, DB2 у IBM, кстати за Oracle и MS тоже выпустила бесплатную версию
DB2 Express-C.

Anatoly Podgoretsky (2006-11-23 15:05:00) [53]
> ANB (23.11.2006 14:15:56) [56]

Может R3 по памяти говорю, а она иногда подводит.
Мощная система, сталкивался с ней, Оракл в ней на нижнем звене. Зарплаты по Норвегии начинаются с 6000 для свежеиспеченого выпускника ВУЗА, если он хотя умеет в ней формы делать. Система очень известная, одна из мировых систем, для построения многозвенных приложений по низкоскоростным сетям.

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

> [61] Jeer © (23.11.06 14:51)
> clickmaker © (23.11.06 14:36) [58]
>
> Ты не горячись.
> Переход с файл-серверных технологий (а многие из тутошних
> через них прошли) на клиент-серверные технологии не должен
> вслепую сопровождаться переносом таковых из первых во вторые
> - разные это миры, разные

а я чего? я ничего. Я предложил один из вариантов, с которым сам работал когда-то. Вполне рабочий вариант. И он реально работает.
Ну не знаю я, как еще можно заблокировать место на схеме зала, чтобы его никто не смог выделить и чтобы при этом не использовать доп. поле. И какие могут быть варианты оповещения других пользователей, кроме как сообщением через промежуточный сервис, либо периодическим опросом с их стороны.
Ну так я здесь и не один. Вот MsGuns пришел и разнес меня. Правда, взамен ничего не предложил.

Jeer (2006-11-23 14:52:00) [55]

> clickmaker © (23.11.06 14:50) [60]

Так и называется:)

Я ее "прошел" в Сбербанке - 5 лет:)

Jeer (2006-11-23 14:51:00) [56]
clickmaker © (23.11.06 14:36) [58]

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

И приходится отделять "мух от котлет" - есть вещи связанные с логико-физическим или бизнес-взаимодействием пользователей.
Когда это раскладывается по полочкам - многое проясняется.

Кроме того, сервера СУБД тоже накладывают свое видение этих процессов: есть блокировочники, есть многоверсионники..

clickmaker (2006-11-23 14:50:00) [57]

> [59] ANB © (23.11.06 14:49)
>
> > система "Опердень" для банков
>
> Да, эт точно. С августа на ней сижу

а она реально так и называется?

ANB (2006-11-23 14:49:00) [58]

> система "Опердень" для банков

Да, эт точно. С августа на ней сижу и еще толком не разобрался, как она работает.

clickmaker (2006-11-23 14:36:00) [59]

> [57] MsGuns © (23.11.06 14:32)

да что вы прицепились к мастерству. Я значок не просил, могу вернуть.
Мне интересно, чем не устраивает мое решение проблемы? И какие оные есть в "нормальныx сиквель-сервера". И что такое "нормальный сиквель-сервер". Оракл? Ну тогда я правда пас, извините...

MsGuns (2006-11-23 14:32:00) [60]
>clickmaker © (23.11.06 14:01) [53]
>да меня возмутил просто наезд г-на MsGuns.
Ничем не обоснованный, кстати. И без любого намека на конструктивизм. Дескать, "я не знаю, как делать, но так - неправильно"

Чем же возмутил ? Если новичок несет ерунду из-за непонимания єлементарных вещей, то "наезды" на него наездами не считаюстя, а если непонимание механизма обмена данными в технологии "клиент-сервер" денонстрирует Мастер, то всем "стоять бояться" ?

Да, знаю. Как и многие здесь. Которые пытаются Вам объяснить, но Вы упорно стоИте на своих "блокировках". И не хотите признать всю чудовищную неуклюжесть своих приемов. Случай с кассирами далеко не самый сложный конфликт, который приходится решать в конкурентных технологиях. Та же система "Опердень" для банков или резервирование в транспорте или гостинницах куда похитрее будет. Однако никаких блокировок в них нет, да и нормальные сиквель-сервера "не знают" ни про какие "блокировки" - это термин из позавчераших локальных технологий.

Если все же обидел, готов принести извинение. Хотя мастерства Вам это вряд ли добавит

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

Наверх

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