Dmitry-SQL Rivkin DmitryПрежде всего. Я бы всем полям дал английские названия или русские но выаписанные латиницей. Второе. Ключевым полям нужно дать разные, но логичные названия. Во всех полях они несут разную смысловую нагрузку, а получается, что они все одинаковые. И мастер будет их астоматом соеденять, при том что они не соеденимы. Третье (самое важное). Таблицу 1 надо похерить, как ненужный, злостный элкмент, при необходимости, ее данные можно перенести во вторую. Четвертую таблицу отправить туда-же. Ключевой номер из третьей будет номером заявки. И весь топик можно будет похоронить, т.к. вопрос сам собой отпадет. (А вы говорите оперировать... )
Спасибо, за советы, но я "не на площади любовью занимаюсь" :)
Такая организация вытекает из организации работы и
"отточенной" последовательности действий, которой я пытаюсь добиться
меньшей "программистской" кровью.
P.S. Где-то было предположение, что аксесс - для "быстрой" разработки,
чем я и занимаюсь. А "тяжелые" вещи будет делать штатный программист,
согласно ТЗ.

Где ты занимаешься любовью - меня инетересует меньше всего :( !
Но то, что ты пвтаешься сделать - это попытка добиться результата максимальной программисткой кровью Когда-то я работал на Газовом промысле инженером и проблемы, нарисованные в твоей схеме таблиц мне очень близки и понятны. Но иея уже не малый опыт программирования и, в том числе, создания таблиц, я уверяю тебя, что чем правильнее и продуманнее созданы таблицы, тем проще и приятнее программисткая работа по ведению этих таблиц. На это же направлены и все ресурсы самого Акса! Он практически безотказно работает на хорошо проработанной структуре таблиц и дает при этом большое количество очень неплохих инструментов.

В твоем, конкретном случае я бы прежде всего создал основную таблицу типа твоей третьей таблы "Мероприятия", хотя на самом деле - это журнал фиксации неисправности, на сонове которого быдут формироваться другие документы. Уникальный счетчик в этой таблице, по-видимому, станет номером заявки. Если на вашем предприятии неисправности классифицируются и по ним идет статистическая обработка, то стоит создать таблицу неисправностей, также с уникальным порядковым номером и полями для описания неисправности и классификации ее, чтобы в дальнейшем можно было легко найти ее в таблице или выяснить, что такой неисправности до сих пор не зафиксировано. Здесь может быть особый разговор, как организовать подобную таблицу, чтобы миминизировать повторные записи (но это - к слову). Если стат обработка не ведется, для описания неисправности достаточно ввести поле Text or Memo и дату фиксации неисправности и кто ее обнаружил. Вот для этого кто ее обнаружил и для исполнитель нужно создать таблицу с их данными и в соответствеющие поля на главной таблице будем вводить только коды юзеров. По большому счету - все.
Теперь создаем форму. Она будет сидеть на главной таблице. На поле "неисправность" в случае если мы создали таблицу неисправностей, посадим комбобокс со списком уже описанных неисправностей. Комбики посадим также на поля юзеров. Теперь, стоит только наступить на новую запись, как асвтоматом создастся номер заявки, т.е. новый номер в главной таблице. Заполнив ее получим все данные для заявки. Если отправим ее на печать, в поле заявка(логическом) поставим True. Если исправность новая, еще не описанная, на событие NotInList комбобокса посадим процедуру, которая откроет небольшую вспомогательную форму для заполнения таблицы неисправностй. То же для новых юзеров. Все
Где еще можно усложнить?