Саныч, по моему ты опять неправ
именно это я и хочу сделать -
может она хочет проверять если в поле1 что-то есть и в зависимости от этого что-то в поле2-поле10 запретить ввод

Тогда надо
1. На событии Current в зависимости от наличия/отсутствия значения в Поле1 запрещать/разрешать ввод данных в Поле2-Поле10
2. На AfterUpdate Поля1 - делать то же, что и в п.1
3. Кроме того, на AfterUpdate Поля2-Поля10 разрешать/запрещать редактирование Поля1 в зависимости от того, есть ли значения хотя бы в одном из полей Поле2-Поле10
4. На каждом AfterUpdate каждого поля я бы сделал принудительное сохранение записи (Me.Dirty = False). Просто так, на всякий случай.
5. Совсем несясно что делать, если к нам пришла запись, в которой заполнены и Поле1, и какие-либо другие поля (2-10). С одной стороны Поле2-10 нередактируемы (непустое значение в Поле1), с другой стороны Поле1 тоже не редактируемо (непустые значения в Поле2-10). Такую ситуацию надо отлавливать и или лечить автоматом, или спрашивать у пользователя что делать.

Саныч, да ты не отмазывайся
Ты дал правильное решение, но не той задачи

Кстати, ту задачу, которую ты решал (т.е. непустое значение может быть только в одном поле, неважно каком), можно сделать принципиально по другому. Все поля всегда открыты, на AfterUpdate любого поля если новое значение - не Null, то сбрасываем в Null все остальные поля. В принципе постановке задачи удовлетворяет ( "если в поле А написали 123456, то в поле В, С, D и так далее никаких таких 123456 ,145789 записей быть не должно" - вот их и не будет)

Это зависит от того, насколько неудобным надо сделать для пользователя изменение данных.

Можно ведь и по твоему - удалил данные из одного поля, забил данные в нужное.
Можно по моему без подтверждения - забил данные, понял что ошибся и начал вспоминать "А что же там было то?"
Можно по моему, но с подтверждением - забил данные в нужное поле, на автомате нажал "Да", начал матерится и вспоминать "А что жа там было то?"

Это уже надо выбирать между удобством ввода и ценностью редактируемых даных.

а на твое 21:09 (извиняй, сразу не заметил) - неправду говоришь
Я в этом случае открываю их все и даю возможность заполнить любое из них (и после АфтерАпдейта все кроме этого поля закроются), а ты в этом же случае закрываешь их все
Ни откуда такое заявление не следует

Вот если заполнено поле1 и еще какое-нибудь (в моем решение от 12:06), тогда все поля закрыты. да и вообще это невозможная ситуация, ее быть не должно. Просто в моем случае ее не поправить никак. Поэтому там собстно п.5 и присутствует.

на твое 00:41
оно может и правильней, но ни фига не влазит в реляционную структуру.

А может и влазит. Надо уже по задаче смотреть.

Тогда расскажи, в чем разница между нашими мировоззрениями на эту задачу.
В моем мировозрении Поле1 выделено по сравнению с полями 2-10. Если в нем что-то есть - в других ничего нет (что было сказано в условии задачи). Если в нем ничего нет - хз, раз ничего не сказано, то в других может быть все что угодно.
В твоем - поля равноценны, но данные только в одном.
И хрен его знает что подразумевала автор вопроса

По поводу "влазит-не влазит" и "входит и выходит"
Что такое перекрестный запрос я знаю. И что такое вертикальная структура хранения - тоже.
Представь что у тебя значения в полях - ссылки на другие сущности. Если какие-нибудь джойны ты еще сумеешь построить, то ссылочную целостность уже никак (если ссылки на разные таблицы)
А еще представь, что значения разных типов. Как ты их будешь хранить? В поле Memo?
Кучу разных сущностей запихнуть в один столбец - это даже первой нормальной формы не получается никак. Тип поля описывается значением другого поля - теоретики баз данных в гробу бы перевернулись
И ни условий на значения, ни значений по умолчанию, ни осмысленных индексов.
Хотя быть может (в зависимости от смысла данных) вертикальная структура здесь и применима. Я же говорю - по задаче надо смотреть.