|
|
|
Блокировка оптимистическая
|
|||
|---|---|---|---|
|
#18+
MS SQL2000(MSDE)+AccessXP.adp На сервере запрос с триггером Instead of. На клиенте связанная форма,где в качестве источника данных SQL-инструкция (этот запрос и еше одна таблица для фильтрации данных). ( присутствует обработчик события OnError для формы,где идет проверка на номер ошибки 7787 и 7878). Select Case DataErr Case 7787 MsgBox strMsg, vbOKOnly + vbInformation, _ "Record Refresh" Response = acDataErrContinue В однопользовательском режиме все работает. Запускаю клиентов на разных машинах и пытаюсь создать конфликт записи при обновлении(блокировка оптимистическая) Ошибка ловится,но на Response = acDataErrContinue никакой реакции и после выхода из этой процедуры появляется сообщение “Multi-step OLE DB operation generated errors.Check each OLE DB status value,if available.No work was done” и обновления записи не происходит. С другой формой,которая отличается только набором полей,все нормально. Как же это понимать?(вопросу уже больше года) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2003, 13:51 |
|
||
|
Блокировка оптимистическая
|
|||
|---|---|---|---|
|
#18+
> и пытаюсь создать конфликт записи при обновлении(блокировка оптимистическая Раскажи и же как ты это пытаешся сделать оптимистическую блокировку на SQL-сервере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2003, 14:19 |
|
||
|
Блокировка оптимистическая
|
|||
|---|---|---|---|
|
#18+
Формулирую по-другому: Access обнаруживает конфликт записи,но на Response = acDataErrContinue никакой реакции и после выхода из этой процедуры появляется сообщение “Multi-step OLE DB operation generated errors.Check each OLE DB status value,if available.No work was done” и обновления записи не происходит. С другой формой,которая отличается только набором полей,все нормально. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2003, 14:47 |
|
||
|
Блокировка оптимистическая
|
|||
|---|---|---|---|
|
#18+
Если аксес обнаруживает конфликт записи - значит он там есть (как мне кажется). Так с какой стати он должен запись апдейтить? Пусть ты даже ему три раза сказал Response = acDataErrContinue ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2003, 15:13 |
|
||
|
Блокировка оптимистическая
|
|||
|---|---|---|---|
|
#18+
Не отображает в форме новые(измененные другим пользователем) данные.В другой форме это происходит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.10.2003, 15:27 |
|
||
|
Блокировка оптимистическая
|
|||
|---|---|---|---|
|
#18+
Может быть кому-нибудь пригодится,поэтому постараюсь по-подробнее описать как решалась данная задача. На сервере запрос с триггером Instead of. На клиенте связанная форма,где в качестве источника данных SQL-инструкция (этот запрос и еше одна таблица для фильтрации данных). ( присутствует обработчик события OnError для формы,где идет проверка на номер ошибки 7787 и 7878). Запрос из четырех таблиц c LEFT JOIN.Связи один-к-одному.Одна таблица главная ,три других –детализация.Чтобы вся эта конструкция была обновляемая,небходимо в запрос включить ключевые поля из всех четырех таблиц.Поля таблицы фильтрации в источник данных не включаются. В качестве уникальной таблицы запрос с триггером.Для нормальной работы в триггере делается проверка на количество обновляемых/удаляемых записей и если таких записей нет-простой выход из триггера. Т.к. запрос c LEFT JOIN,то возможна ситуация ,когда ключевые поля таблиц детализации в запросе будут Null. Именно это и вызывало в моем случае сообщение об ошибке “Multi-step OLE DB operation generated errors.Check each OLE DB status value,if available.No work was done”,т.к. выяснилось,что Ассess не может самостоятельно сформировать команду синхронизации с условием Where ГлТаб.Ключ=? and ТабДет1.Ключ Is Null и т.д. Решение: на событие формы BeforUpdate в зависимости от значений Me. ТабДет(1,2,3)Ключ самому формировать команду синхронизации(точная копия источника записей формы без Where+ Where ГлТаб.Ключ=? and ТабДет1.Ключ Is Null и т.д. ) (сами поля ТабДет(1,2,3)Ключ на форму можно не помещать). Чтобы при вставке записей не появлялось сообщение о противоречии с базовым источником записей, пришлось вручную делать на событие формы BeforUpdate Me.ТабДет(1,2,3)Ключ= Me.ГлТаб.Ключ по логике приложения. Остается один вопрос:если первый пользователь изменил запись,а второй без изменения своей копии пытается ее удалить,то появляется ошибка 32 «Row cannot be located for updating. Some values may have been changed since it was last read»,хотя по-моему следовало бы выдать ошибку WriteCoflict,а так придется каким-нибудь образом вручную обновлять запись. Собственно вопрос: ошибка 32 это предусмотренная реакция Ассess на данную ситуацию или нет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 08.12.2003, 17:37 |
|
||
|
|

start [/forum/topic.php?fid=45&fpage=1709&tid=1677773]: |
0ms |
get settings: |
11ms |
get forum list: |
18ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
46ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
| others: | 240ms |
| total: | 394ms |

| 0 / 0 |
