2 Aijik

Я в общем со всем согласен. Имеет место недопонимание. Кода я говорю, что уникальные индексы и внешние ключи не важны, то я имею ввиду, что они не важны только в контексте данного разговора, они ЛОГИЧЕСКИ выполняют другую функцию. А вообще они конечно же важны и повышают производительность. Кстати не во всех SQL серверах индексы на внешних ключах создаются по умолчанию.

>Что значит "положение записи может измениться"? Значение индекса изменится всмысле?

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

>Ну и нехай изменяется. Синхронизация с сетевым источником в Файл-сервере происходит автоматом по определенному интервалу - я уже писал об этом.

Ну не само же оно просисходит. Об этом подумали разработчики и написали соответствующий нетривиальный код. Больше кода - больше ошибок. Синхронизация это всегда сложная логика, причем многие конфликты автоматически не решаются. Я подозреваю, что разработчики просто блокируют заведомо с запасом, чтоб не морочить себе голову. Не зря же народ так ругает акцес в многопользовательском режиме (его точно, я знаю живые примеры, наверное и фокспро тоже ругает).

>Зачем что-то блокировать? Тем более ТАБЛИЦУ. Для просмотра вообще ничего блокировать не надо.

Нужно. Это если стоит dirty read (не помню точно, можно посмотреть в документации), то не нужно, а на более высоких уровнях изоляции нужно блокировать и при селекте, чтоб гарантировать, что пользователь видит актуальное состояние базы.