Драсте...
Подобную (почти) задачу решил другим вариантом:
Есть временная локальная таблица, содержащая два поля - ID(тип соответствует типу ключевого поля "основной" таблицы) и Mark(логический), хотя, можно обойтись и одним ID (у меня задача была несколько путанней, поэтому во временной использовалось много больше полей).
Временная таблица - пустая, т.е. перед открытием формы нужно ее чистить.

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

ДА! Маленький "минус"... Набор должен быть несогласованным... Мне сначало было страшно, но потом ничего... привык :)

Плюсов при этом достаточно много:
- достижение поставленной задачи;
- никаких "сливаний" во временные таблицы;
- никаких лишних данных (тока временно временные:);
- абсолютно естественная дальнейшая обработка средствами SQL;
- ну может еще чего...

з.ы. не бейте сильно... сами мы не местные...

Да, Владимир Саныч прав. Поле из временной таблицы надо отобразить в форме и при вводе Пользователем в нее данных (например при отметке чекбокса) во временную таблицу автоматически добавляются данные...
Единственное, что я упустил, это то, что связь "основной" таблицы со "временной" (пустой в момент открытия формы) должна быть "правой", т.е. все записи из основной таблицы и только те из временной, которые соответствуют основной... Теперь вроде (и самому) понятней :)

Значит я плохо объяснил :)

Открытие формы:
Пользователь отметил Укроп, что приводит к добавлению записи во врем.табл:

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

для ЛП (если прикалывается):
Сам такой! :)

для ЛП (если не прикалывается):
ЛП, а сколько мне это решение в своё время гемора стоило... Досих пор помню название своего топика в котором оно и нашлось: "Риторические вопросы из тупика" :) Хорошо, что тогда модераторов небыло, а то в угол бы за такую тему поставили бы

Ну так что, ЛП, еще одного ЖИРНОГО енота я заработал от тебя? :) //Не помню за что был первый, но, надеюсь, к следующему году (когда планирую побывать в Первопристольной) вспомню и мы их отметим за бутылочкой пива :)

Саныч, ну да. На более позднем (момент обработки группы) всё так, как ты и сказал. Вообщем, сорри за косноязычность... :)

для АндрейК:
Ну вот, теперь ЖИРНОГО я фиг получу точно :)

Щас проверил... Если запрос не слишком сложен и именно содержит Основную таблицу и Временную таблицу, то набор можно оставить Согласованным и всё будет работать именно так, как я и сказал: юзер кликает на временном чекбоксе и запись автоматически добавляется во временную таблицу с необходимой ID-шкой... Т.е. главный заявленный мной недостаток (несогласованный набор записей) снимается! Остается, правда, как оказалось и как я сейчас вспомнил "неопределенное состояние чекбокса", которое лично у меня получилось таки обратить в достоинство :)

По поводу моих настырных утверждений о несогласованном наборе... Пойду погляжу в свой "запомнившийся" топик... Посмотрел... В моем случае объединялись таблицы, связанные отношением "многие-ко-многим" (через еще одну таблицу), в результате попытки реализовать рассматриваемый вариант появлялась ошибка "Невозможен ввод значения в пустое поле со стороны "один" внешнего объединения." Поэтому набор пришлось делать несогласованным и, коль скоро он несогласован (т.е. Акс умыл руки в плане поддержания реляционной целостности), то я "ручками" в коде после изменения пользователем логического поля брал и копировал ID текущей измененной пользователем записи в ID-поле временной таблицы этой же самой записи... Цена показалась мне не очень высокой и решение реально сейчас работает у одного клиета. Проблем с данным решением нет. В целом с базой есть :), а с этим решением - нет.

Ну и в качестве оправдания:
Не относись ко мне серьезно, делай как все! :) Ибо так получилось, что Аксом я щас очень мало занимаюсь, поэтому вроде бы элементарные когда-то для меня вещи стали вдруг какими-то расплывчатыми и зыбкими

Удачи!
Иван ака Нуф.

для АндрейК:

Ну так не честно, в самом деле... :) Уже ж вроде всё досканально рассказано, проверено даже (еще раз:)!
АндрейК1. Если я объединяю 2 таблицы и не указываю "несогласованный набор", то не получается изменить флажок - "объект Recordset не является обновляемым". В запросе всего 2 таблицы, одна - пустая (с двумя полями), другая с данными.
В запросе две таблицы или другой запрос и временная таблица? Если именно две таблицы, то Вы уверены, что ID обеих таблиц имеют одинаковый тип? Если всё так, то... То что-то вы не так делаете... Что бы еще один разок не "обламаться", приведу выполненный мной специальный тест (A2000, хотя роли не играет):

Если после подобного повторения, записи во временную таблицу при изменении поля Bool не добавляются, то один из нас точно что-то не так делает.
Если записи у вас всё же в указанном мной тесте добавляются, то что-то не так со своим реальным вариантом делаете Вы. Что именно - хз... Возможно, как уже сказал, объединяете некий сложный запрос с временной таблицей, от чего набор становится нередактируемым, возможно что-то другое... Телепатировать так и не научился :(

АндрейКТак всё-таки данные в поле ID временной, оказывается, заносятся не "автоматически", а либо ручками, либо специальной процедурой?
В простейшем (описанном мной) случае данные заносятся автоматически, и только в случае сложных запросов приходится делать набор несогласованным и вставлять следующий код в процедуру, которая изменяет поле во временной таблице (обработка события "Клик"/"Чэндж"/"Афтер/БефорАпдэйт"/прочие по желанию):
Me("TempID") = Ме("ID")
или
Me.Recordset("TempID") = Ме.Recordset("ID")
или
Me.RecordsetClone("TempID") = Ме.RecordsetClone("ID")
Я просто не помню... Поиграйтесь с этой строкой в случае несогласованного набора записей...