ВОПРОС 1. Возникнут ли у меня ошибки при работе в сети, если я с двумя FREE TABLES провожу подобную операцию удаления?

* ВОПРОС 2: нужна ли след. строка для конкретно для этой задачи?

Set Exclusive Off
Set Multilocks On
Use teams In 0 Shared
Use players In 0 Shared
CursorSetProp("Buffering",5,'teams')
CursorSetProp("Buffering",5,'players')
...
Locate For teams.Name='Алания'
...
If 6=Messagebox('Удалить?',4+32+256)

Delete All For players.idTeam=teams.idTeam In players
* ВОПРОС 3. Стоит ли заменить предыдущую строку нижеследующей?
* DELETE FROM players WHERE players.idTeam=teams.idTeam
IF Tableupdate(.T.,.T.,'players')
* успешно удалены игроки
ENDIF

Delete In teams
IF Tableupdate(.F.,.T.,'teams')
* успешно удалена команда
ENDIF

Endif

Собственно, ЗАГОГУЛИНА :) в том, что подходящий примерчик из книги с TRANSACTION тут не применить, т.к. это - не БД. А операция массового удаления в players не проверяет успешность удаления каждой конкретной записи. Может, цикл писать на проверку TableUpdate()=.T. ?
Или TableUpdate(.T.,.T.) все нипочем, лишь бы сервер не отрубился?
А вариант DELETE-SQL вроде сам должен разобраться с блокировками и удалениями...

ВОПРОС 1. У меня 8-й VFP. Стало быть, транзакции free tables не для меня ?

ВОПРОС 2. Ошибочка вышла, следует читать так:

* ВОПРОС: нужна ли следующая строка конкретно для этой задачи?
Set Multilocks On
…..

Кстати, после вашего ответа, появился новый
ВОПРОС 2а
А если в тот момент, когда идет удаление в дочернем файле, в родительском "доброжелатели грохнут" запись для сравнения? С чем тогда сравнивать? Или эталон в любом случае остается в моем буфере, пока я его сам не "замочу"?

ВОПРОС 3. Почему команда Delete-SQL не сможет найти все нужные записи? Если она будет проверять условие WHERE не в буфере, а в исходной таблице, то это ж еще лучше. Там-то все реальные записи и живут. Или она непредсказуемо выбирает место своей деятельности: буфер или таблицу?
"…если для твоей задачи это не имеет значения, то можешь и не блокировать таблицы."
Это как надо понимать ? То, что я поиграл с буфером, а в таблицу реально ничего не сбрасываю? Или то, что у меня незагруженная сеть и столь редки конфликтные ситуации, что особенно и беспокоиться не о чем?
********************************
За основу сброса изменений взял ваш, Владимир М., примерный код кнопки "Сохранить" в режиме оптимистической табличной буферизации (5)
Правда, у меня не БД, а отдельные таблицы. Поэтому пришлось закомментировать следующие три строки:
BEGIN TRANSACTION
END TRANSACTION
ROLLBACK

Но при следующей последовательности событий выплыл эффект реанимации:

1. Первый user открывает запись на корректировку.
2. Второй тем временем удаляет эту запись
3. Пытается сбросить изменения с Tableupdate(.F., .F.)
4. Естественно появляется предложение записать поверх.
5. Ответ "ДА".
6. Tableupdate(.F., .T.)

И тут чудо: удаленная запись восстанавливается со значениями первого user.

По логике, думаю, так и должно быть. Все бы ничего, но могли быть удалены связанные записи в дочерних free tables. Поэтому у меня

ВОПРОС 4. Вы даете примерный код, не утруждаясь на доп. разбор такой мелочи? И в код программы нужно внести доп. обработку записи?
Типа:

IF Curval("Deleted()")
=MessageBox('А записи-то уже нет, дружок!', 0)
ENDIF

ВОПРОС 5. Если я сам собираюсь изменить/удалить связанную с нею группу дочерних, то могу я так поступить?

SELECT players
DELETE ALL FOR players.idTeam=teams.idTeam IN players
IF FLOCK() = .T.
=TABLEUPDATE(.T.,.T.)
UNLOCK
ENDIF

Или вторую и третью строки программы стоит поменять местами?

Кстати, непонятно, в чем преимущество DELETE-SQL перед DELETE, если особого тока от ее блокировок нет? Да еще и может уменьшить производительность. Или оно только в БД проявляется?

ВОПРОС 6. Собственно у меня нет полной ясности с Tableupdated( lAllRows) ,
когда lAllRows =.T.
Скорость работы при оптимистической буферизации сильно зависит от того, 3-я это или 5-я? Или 5-я буферизация была введена, по большей части, для подобных однострочных, но "оптовых" операций с записями, а не для ускорения скорости путем "накопительства"? Не лучше ли, не отходя от кассы, сразу обрабатывать текущие изменения, не накапливая "на потом"? Но для этого, вроде есть "3-й вид оптимизма".

7. Кстати, а есть возможность сбрасывать, например в WORD, блоки русскоязычного текста в толковой кодировке?

Конечно, скучно помогать упрямцу следующему порочным маршрутом. :)

Владимир М., я согласен с вами, БД была бы правильнее F/Tables. Но проблема в том, что у меня не получается классическое, как в книжных примерах, построение. Глядя на то, как она организуется, я не пойму, как этот "уродец" будет жить?

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

1. справочник по агентам: agent
- idAGENT (AutoInc, код агента),
- nOPERATOR (оператор, последним работавший со справочной информацией по этому агенту),
- прочая справочная информация об агенте.

2. справочник по операторам: operator
- idOPERATOR (AutoInc код оператора),
- прочая справочная информация по оператору.

3. справочник по городам town
- idTOWN (AutoInc, код города),
- прочая справочная информация по городу.

4. собственно рабочий файл zakaz
- nAGENT агент
- nTOWN_FROM (откуда товар взял)
- nTOWN_TO (куда перевез)
- nOPERATOR (оператор, оформивший заказ)
- прочая информация

Как видно, справочник по операторам должен быть прицеплен сразу к agent и zakaz, а справочник town к двум полям в zakaz.

Если все эти 4 файла сцепить нитками связей в Database–дизайнере, то мне кажется, что ничего не будет работать, т.к. этот квартет будут раздирать внутренние противоречия. В файлах zakaz и operator VFP может потребоваться одновременно сделать активными по 2 записи. А открывать дополнительные курсоры Designer не позволяет, хотя и не возражает против столь дикой, IMHO, реляции файлов в БД.

5-мин. экспериментом тут не отделаешься, тем более, что одних только справочников у меня далеко не 3. Поэтому я и направился по пути free tables. Мне казалось, что так проще надежнее…

Может, я зря в панику ударяюсь? И VFP прекрасно "разрулит" все дела в этой БД?

"Вы перепутали понятия"
Понял, что означает эта фраза, только после того, как экспериментальный вариант БД заработал.
:)
Вы правы. Подобные "нитки" (2 к 1 и 1 к 2) прокатывают.

Что не понравилось:
1. Надоело везде выставлять RESTRICT после каждого изменения. Чуть поменял что-то в структуре файла или чихнул, – тут же исправляй REFERENTIAL INTEGRITY. Они по умолчанию упрямо превращаются в IGNORE.
Есть способ, чтобы сразу все состояния перегонять в RESTRICT?

2. Когда ввожу новую запись, (например, в zakaz), хотелось все пункты формы-бланка содержали белые (пустые) поля. Видно, где уже данные ввел, а где нет. В реальной задаче миллион справочников, и не все поля вводится по порядку. Бланк будет содержать многостраничный PageFrame и от значений будет в глазах рябить. .NULL. не во всех случаях допустимо, а непустой default может оказаться не таким, что нужно по логике задачи. Смотришь, вроде все заполнено, а что-то забыл переставить в нужное состояние, и "пошла" гулять ошибка оператора, хотя INTEGRITY is OK.

APPEND BLANK с готовыми пустыми значениями вызывает ошибку триггера, а присваивать default "абы что-нибудь" не хочется… Как и вводить в справочники нулевые значения.
Пришлось навесить на кнопку НОВАЯ ЗАПИСЬ дополнительно

APPEND BLANK (со значениями default)
SCATTER memvar BLANK EXCEPT поля AutoInc
GATHER memvar

чтобы переписать значения "удобной пустотой". Ведь до тех пор, пока не сделана TABLEUPDATE ошибки не будет…
Что обычно делают в этих случаях?

3. Когда при вводе происходит ошибка, то непонятно, в каком из полей произошло нарушение целостности. Приходится пробежаться по всем, проверить самому. В Free Tables так и делал, чтобы ошибки не было. Вешал на кнопку СОХРАНИТЬ что-то вроде:

Do Case
Case Empty(mycursor.MYFIELD) && или иная проверка
Thisform.Pageframe1.ActivePage=1
Thisform.Pageframe1.Page1.tMYFIELD.SetFocus()
…..
Endcase

Может, где-то имеется готовая ссылка на поле – причину беспокойства триггера? Aerror() не возвращает, вроде…