Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Блокировка записей
|
|||
|---|---|---|---|
|
#18+
Я вытаскиваю таблицы с SQL Server (CREATE SQL VIEW). Нужно ли Fox-ом обрабатывать блокировку записей? (Для начинающих) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 05:22 |
|
||
|
Блокировка записей
|
|||
|---|---|---|---|
|
#18+
Вам необходимо конкретизировать вопросы... Абсолютно не могу понять о че вы спрашиваете. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 07:54 |
|
||
|
Блокировка записей
|
|||
|---|---|---|---|
|
#18+
Данные храняться на SQL-сервере. Когда Вы открываете Remote View, то Вы фактически выполняете запрос (SELECT-SQL) к серверу. Т.е. на клиент попадают не сами исходные данные, а их копия. А какой смысл блокировать копию данных? Более того, если Remote View открываются в Private DataSession (или в разных экземплярах FoxPro), то их содержимое абсолютно независимо друг от друга. Разные копии. Другой вопрос, надо ли блокировать данные на самом SQL-сервере? В принципе, иногда возникает такая необходимость и, также, в принципе, это можно осуществить. НО! Крайне нежелательно это делать. Особенно для начинающих. Отдайте разрешение конфликтов блокировок самому серверу. Поверьте, он справится с этим лучше Вас. От Вас потребуется только разрешение конфликтов совместного доступа. Т.е. ситуации, когда одни и те же данные модифицируеются несколькими пользователями одновременно. Эта ситуация отлавливается примерно так: Код: plaintext 1. 2. 3. 4. 5. 6. 7. Т.е. второй параметр в команде TableUpdate() как раз и управляет вопросом: писать поверх изменений другого пользователя или выдать ошибку 1585 Правда, прежде чем писать такую обработку следует подумать: а оно Вам надо? Т.е. есть ли необходимость в таком анализе? Возможно, если всегда писать поверх изменений других пользователей ничего страшного не произойдет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2004, 09:47 |
|
||
|
Блокировка записей
|
|||
|---|---|---|---|
|
#18+
Это так при условии что одна и тажа запись редактируется пользователями по очереди. Но как отлавить те моменты когда эта запись нужна нескольким пользователям одновременно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 01:08 |
|
||
|
Блокировка записей
|
|||
|---|---|---|---|
|
#18+
Spavel_74Это так при условии что одна и тажа запись редактируется пользователями по очереди. Но как отлавить те моменты когда эта запись нужна нескольким пользователям одновременно ВладимирМ все же популярно объяснил! Попробую объяснить еще раз, попроще. Запись МОЖЕТ РЕДАКТИРОВАТЬСЯ НЕСКОЛЬКИМИ ПОЛЬЗОВАТЕЛЯМИ ОДНОВРЕМЕННО . Но ЛОКАЛЬНО , т.е на компьютере пользователя. Однако, ФИЗИЧЕСКИ записываться может всегда (!) только у кого-то одного . Остальные ждут своей очереди, т.е. ждут пока запись освободится. Вот этот "момент" отлавливается и предлагается пользователю для осмысления в приведенном ВладимиромМ фрагменте. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2004, 06:52 |
|
||
|
|

start [/forum/topic.php?fid=41&msg=32721506&tid=1595693]: |
0ms |
get settings: |
6ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
83ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 235ms |
| total: | 411ms |

| 0 / 0 |
