| ** avtoritet |
| Отправлено: 25.07.2005, 04:25 |
|
Не зарегистрирован
|
Hi!
Сервер МССКЛ 2000, TADOConnection, TADOQUery.
Задача такая:
code:
try{
QueryRaion->Edit();
QueryRaion->FieldByName("K_RAIONNAME")->Value = dtEditRaion-> Text;
QueryRaion->Post();
}catch(Exception &excep){
QueryRaion->Cancel();
ShowMessage(excep.Message);
}
Надо изменить запись, но эту запись уже изменил кто-то другой. В это случае я получаю сообщение (что-то типа, запись изменилась клиентом). У этого сообщения есть номер, как взять номер сообщение вообще?
Вдогонку: обновлять запрос в моей ситуации не резонно. |
|
| olegenty |
| Отправлено: 27.07.2005, 14:20 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
как вариант: http://www.rsdn.ru/article/?157
|
|
| ** avtoritet |
| Отправлено: 28.07.2005, 02:34 |
|
Не зарегистрирован
|
to olegenty:
В этой статье я не нашел того что нужно. Или же плохо читал. Я ведь получаю текст ошибки через класс Exception, а мне бы не текст, а код этой ошибки как-то отловить, а потом текст немного изменит.
Вот вопросик еще назрел: Как мне сделать так, чтобы в клиент-приложение нельзя было изменять запись, если она запрошена несколькими клиент-приложениями. То есть, если у Васи в запросе есть запись, например, "Кукушка", то Вася не мог бы изменить ее на "Дятел" или удалить, так как у Пети тожы в запрос входит запись "Кукушка"?
Что-то бойду какую-то написал! Может кому-нибудь не понятно о чем я? |
|
| olegenty |
| Отправлено: 28.07.2005, 07:16 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
Ну тогда ты много раз по десять невнимательно читал. Среднее звено тебе для этого и нужно. О чём идёт речь в статье.
Код же ошибки выбирай из реального класса ошибки.
|
|
| AVC |
| Отправлено: 28.07.2005, 08:42 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
| QUOTE |
Вот вопросик еще назрел: Как мне сделать так, чтобы в клиент-приложение нельзя было изменять запись, если она запрошена несколькими клиент-приложениями.
|
Если запись запрошена на просмотр, то, скорее всего, проще как написал olegenty (в условиях MSSQL где я слабо знаком с системой блокировок). А вообще это достигается инструкцией Select for Update.
Но вам действительно нужно именно это? Обычно нужно что бы два или более пользователя не могли одновременно изменять одну запись. Тогда почитайте об оптимистических и пессимистических блокировках.
|
|
| olegenty |
| Отправлено: 28.07.2005, 10:29 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
2 AVC — разве это приведёт к ошибке? просто все встанут в очередь... или Oracle даст остальным читать последнее подтверждённое состояние? в MSSQL тоже можно поэкспериментировать с хинтами и добиться такого эффекта, только
1. нет гарантии, что этот мегаумный сервер заблокирует всего одну запись, а не экстент/страницу/таблицу. он, гад, сам принимает это решение, и на соображения разработчика/пользователся кладёт с прибором. в его терминологии это называется "эскалация блокировок"
2. таки, запись будет заблокирована ВООБЩЕ, т.е. её и не прочитаешь, а встанешь в очередь до тех пор, пока либо её не отпустит заблокировавшее соединение (тут зависит от уровня изоляции транзакции, но для Read Committed будет именно так), либо отвалишься по таймауту.
|
|
| avc* |
| Отправлено: 28.07.2005, 10:50 |
|
Не зарегистрирован
|
olegenty
| QUOTE |
разве это приведёт к ошибке? просто все встанут в очередь...
|
Что "это"? Непонял.
| QUOTE |
или Oracle даст остальным читать последнее подтверждённое состояние?
|
Именно так. Это начинается с уровня изолированности ReadCommited. А более низкие Oracl'у не нужны и он их не поддерживает.
Ты говорил у тебя есть Том Кайт. Посмотри главу 3 — у меня бежали слезы умиления, когда я её читал. |
|
| olegenty |
| Отправлено: 28.07.2005, 11:02 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
2 AVC — под "это" понимается блокировка записи. ты уже ответил, что Oracle заблокирует только модификацию. MSSQL же заблокирует на ВСЁ, в том числе и на чтение. Такой вот он бодрый.
|
|
| avc* |
| Отправлено: 28.07.2005, 11:09 |
|
Не зарегистрирован
|
Ну тогда только оптимистичная блокировка с немедленным завершением транзакции (с чего начали к тому и пришли), а я себе могу позволить и пессимистичную и в длительной транзакции.  |
|
| ** avtoritet |
| Отправлено: 28.07.2005, 11:56 |
|
Не зарегистрирован
|
А почему бы не пессимистическую блокировку? Как юзер только начал редактиовать, так сразу другим на это дело шляпа? А вообще реально ли сделать так: Петя и Вася открыли себе два запроса. Обоим в запрос вошла запись "Кукушка", но никто, ни Вася ни Петя, не могут ее (именно "кукушку")отредактировать. Пока Вася не отключится или не вызовет запрос, куда не входит "Кукушка", Петя редактировать "Кукушку не может" и наоборот? |
|
| olegenty |
| Отправлено: 28.07.2005, 12:32 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
да всё не так, на самом-то деле. приведу пример, как это у меня реализовано (не обязательно делать так, но противоречий не возникает)
1. Пользуюсь ТОЛЬКО клиентскими наборами данных.
2. Петя и Вася получают выборку, при этом к обоим попадает кукушка.
3. Оба начинают редактировать кукушку.
4. А дальше варианты развития событий.
4.1. "кукушка" — не ключевое поле, а только атрибут. кто-то из ребят подтвердил ввод первым, "кукушка" стала "соловьём". на время update MSSQL блокирует запись эксклюзивно, т.е. все остальные, кто что-то хочет от записи, ждут подтверждения/отката транзакции, вызвавшей эксклюзивную блокировку. кто-то из ребят — вторым. при этом его действие дождалось предыдущего изменения, а затем превратило "соловья" в "крокодильчика с крыльями". и все счастливы.
4.2. "кукушка" — ключевое поле. тогда всё повторяется, вот только тот, кто вторым пытался сделать изменение, получит сообшение, что запись изменена, либо удалена, и ничего не произойдёт. он просто будет вынужден перечитать выборку, чтобы увидеть реальный набор данных. (такая ситуация у меня невозможна, ключевые поля никогда не меняются)
|
|
| avc* |
| Отправлено: 28.07.2005, 12:54 |
|
Не зарегистрирован
|
4.1 А я бы не превращал соловья в крокодильчика а дал бы второму возможность увидеть, что стало с кукушкой. (классика). Но это все зависит от алгоритма. |
|
| olegenty |
| Отправлено: 28.07.2005, 14:34 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
угу, это я могу легко. но не делаю (не просили). но мне пофиг потому, что я имею свои мета-мета таблицы, где хранится вся инфа о действиях пользователей. и "откатиться" на "соловья" проблемы не составляет.
|
|
| ** avtoritet |
| Отправлено: 29.07.2005, 12:55 |
|
Не зарегистрирован
|
Вроде как разобрался. Olegenty не подскажешь как огранизовать такие вот мета-мета таблицы для слежки действий пользователя (я. как пониаю, обрабать их сервер?) или может в инете есть где что почитать. |
|
| olegenty |
| Отправлено: 29.07.2005, 13:19 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
теория по ООБД — в самый раз. например вот тут: http://ooad.asf.ru/
я для этого использую четыре ключевых таблицы:
1. Класс (Class) — содержит идентификаторы и наименования классов
2. Экземпляр класса (Instance) — содержит идентификатор класса, идентификатор экземпляра класса и ряд полей, позволяющих оперировать данными текущего состояния
3. Действие пользователя (Action) — содержит идентификатор действия пользователя, идентификатор действия, которое каскадно привело к данному, идентификатор типа действия пользователя, время действия пользователя, идентификатор пользователя, наименование хоста, с которого это действие осуществлялось. Действия могут быть следующего типа
3.1 Вставка пользователем
3.2 Обновление пользователем
3.3 Удаление пользователем
3.4 Подтверждение
3.5 Откат
3.х — набор действий, которые каскадно приводят одному или нескольким из первых трёх.
4. Состояние экземпляра класса на этапе цикла существования (Cycle) — содержит идентификатор экземпляра класса, идентификатор состояния, идентификатор предыдущего состояния, идентификатор действия, приведшего к данному состоянию и ещё ряд избыточных полей для ускорения некторых выборок
5. Таблицы данных, которые содержат идентификаторы состояний экземпляров классов и все атрибуты, которыми эти классы характеризуются.
НО!!! использование подобной модели
1. Требует ОФИГЕНОЙ проработки структуры БД, иначе всё будет тормозить не по детски, что неприемлемо
2. Требует следования жестким правилам, ибо СВЯЗИ между объектами уже не реляционные, а на уровне хранимых процедур, и привести систему к нецелостному состоянию — пара пустяков.
|
|
| AVC |
| Отправлено: 29.07.2005, 13:50 |
|
Ветеран
Группа: Модератор
Сообщений: 1583
|
Спасибо Oracl'у. Триггера уровня "строка" всех основных таблиц записывают старое состояние записи в такую-же таблицу схемы SPY и заполняют поля кто, когда, что сделал. Кто, когда создал запись — автозаполняемые поля основной схемы. Тормоза незаметны. Но в схеме SPY уже ни какой целостности, да это и не надо. По специфики предприятия основная операция модификации — Insert. |
|
| ** avtoritet |
| Отправлено: 29.07.2005, 13:55 |
|
Не зарегистрирован
|
Спасибо всем, пойду по сылке по швыряю! |
|
| olegenty |
| Отправлено: 29.07.2005, 14:00 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
твою мать!!! а я тут целую шнягу развёл, не один месяц потратил, чтобы всё это заработало... НО! MSSQL мне навязан сверху, это объективная реальность, данная в ощущении бесполезной работы 
|
|
| ** avtoritet |
| Отправлено: 30.07.2005, 05:29 |
|
Не зарегистрирован
|
то olegenty:
В каком смысле шнягу развел? МССКЛ не любишь? |
|
| olegenty |
| Отправлено: 30.07.2005, 06:45 |
|
Ветеран
Группа: Модератор
Сообщений: 2412
|
ну вот это отслеживание мне понадобилось, поскольку по ТЗ есть 2 типа пользователей: одни вводят, другие подтверждают ввод. т.е. объект вообще может находиться в нескольких целостных состояниях: последнее подтверждённое и текущее. при этом неподтверждённых состояний тоже может быть несколько, и проверяющий может подтвердить их, а может откатиться на любое из них. но тупиковые ветки неподтверждённых откаченных записей всё равно остаются в системе, для последующих разборов полётов. опять же, "просмотровые" пользователи видят ТОЛЬКО подтверждённые состояния. помимо прочего, ряд объектов не требуют проверки, поэтому всегда "автоподтверждаются", а ряд объектов вообще не нуждается в отслеживании (кодификаторы различные), поэтому хранятся "по старинке". ну и действия ранжируются. т.е. часть действий обязательно подтверждается всегда, независимо от того, с каким объектом производится работа. в основном это импорты.
поэтому, тут я зря о шняге, простой истории мне мало. но MSSQL не прсто не люблю — он меня от "раздражает" до "бесит", хотя теперь я с ним практически на "ты". вот отсюда и эмоции.
|
|
| ** avtoritet |
| Отправлено: 30.07.2005, 11:37 |
|
Не зарегистрирован
|
Меня тоже MSSQL бесит, потому что я с ним не на "ты"! Надеюсь это временно! Исправляюсь потихоньку |
|
