-garik-,
И Вы надеетесь что на этот вопрос,не видя схему,кто-то ответит

-garik-,
А почему Вы решили что повторения в индексах(если они разрешены)?
Ведь в сообщении:... "из-за повторений в индексе,ключевых полях "...

Не "возможно",а только в них и индексы не при чем,от слова совсем.
Все-таки покажите схему(или её фрагмент). После внесения записи в таблицу\форму на ней,в какой момент выводится сообщение и поподробней про "редактирование формы в конструкторе" Типа:"до этого все было ОК"

На вскидку-большое число связей без обеспечения целостности,это и приводит к возникновению ошибки и сложности в её выявления + где ключевые поля(на схеме не наблюдается ни одного "ключика")
(лично я использую подобные связи только в случаях когда поле связи\combo в форме необходимо оставить пустым) А ещё неизвестно какую(ие)задачу решает ТС-судя по объему схемы что-то грандиозное.
Смутно подозреваю что таблиц надо поменьше.Не опишите ли,вкратце,задачу,стоящую перед Вами(БД)?.Тогда помогу
Считаю что ошибки(не только та,с которой Вы уже столкнулись )будут,даже если обойдете эту. Невозможность установить связь с сохранением целостности-явное указание на ошибки в проектировании-а связи без целостности должны быть редким и осознанным исключением

Прошу пардону-быстро же я забыл 2003-2010 то рисует ключики

В Вашей схеме особо не разбирался,но предлагаю такой вариант схемы.
Затем форма "протокол" с рядом подчиненных "датчик..N" и отчет с источником тбл."протокол"
недостаток:доработка БД при добавлении нового датчика\результата(хотя можно предусмотреть пару резервных):

Количество таблиц:главная+по числу сущностей(а сущностей то всего две:датчики и результат измерений*числоДатчиков)+какие-то вспомогательные.

Вернее так (или еще одна форма с возможностью выбора датчика или в многопользовательской среде-каждому пользователю свой датчик-короче есть варианты-придумывайте сами)

Наверно экономили....Когда Вам "разработчик" втюхал БД со связями без сохранения целостности данных. Мучайтесь теперь сами с такой БД.
Удачи!

DarkMan,
Я выдал общее направление проектирования и указал недостаток такого варианта.Естессно разработчик, зная о нем, должен принять меры по его исключению,а вот как это сделать(
(есть варианты)-его решение. Разрабатывать "боевую" БД и рассматривать все возможные,при этом варианты, я не намерен.

DarkMan,
Щаз,только шнурки поглажу...

ПыСЫ:
Основная мысль которую я хотел донести ТСу(не дошло что надо объяснить подробней это основополагающее правило для любой БД ): количество таблиц=количество сущностей (которые надо определить еще только подходя к компутеру. Если определить больше чем есть-излишествующая информация)+объединяющая тбл.сущностей(главная)+если надо,какие-то вспомогательные.Речь о том что датчики,измерения есть всего две сущности и плодить множество таблиц есть совсем не правильно-одно дополнительное поле-признак избавляет от "рожания" кучи лишних/однотипных таблиц

Это Ваше субъективное мнение и не более того,а вот нарушения основополагающх правил еще никому не позволили создать нормальную БД. Одна большая таблица всяко лучше,а главное правильнее,чем куча однотипных таблиц описывающих одну и ту же сущность. Тем более что таблица в 15-30 (а при необходимости и больше-поинтересуйтесь у опытных людей часто ли они пользуются связью один-к-одному и пользуются ли вообще) полей это вполне нормально.
Советую разобраться что такое сущность и что такое её атрибуты,а в дальнейшем не путать одно с другим и после этого проанализировать Вашу схему
За сим откланиваюсь