Очевидно что null не проверяется.
И никакого прикола здесь нет
Поля надо делать обязательными - если они должны быть обязательными. А не перекладывать проверку наличия значения на внешний ключ.

А как же "объединять только те записи, в которых значение поля такого-то совпадает..." ? Это что, Access считает, что Null совпадает с не Null? Т.е. (Null=1)=True?
А что, у вас запрос на объединение умудрился объединить запись с Null'ом и запись со значением "1" в полях связи? Не рассказывайте сказки.

это значит ,как верно указывает йййй,что FOREIGN KEY НЕЛЬЗЯ строить на поле,если оно не NOT NULL!
Я??? Нет, я такого не мог указывать. Очень даже льзя строить Foreign Key на необязательном поле. Иначе как, например, строить связь один-ко-многим с необязательным вхождением со стороны многие?

Обязательное поле - это обязательное поле. Внешний ключ - это внешний ключ. Не надо путать теплое с мягким.

Только нормальная прога ударила бы меня по рукам еще в момент построения связи и сказала бы - мол, нельзя так, а надо так и вот так.
Чего нельзя? Связь нельзя делать по необязательному полю? Да кто вам такую чушь сказал?

Вот Visual FoxPro вроде стразу говорит - типа, индекс соответствующий сделай сначала, потом объединяй...
Ну а аксес и индекс сам делает для связи.
Или вам кто-то сказал, что нельзя индексировать необязательные поля?

Не есть ли это грубая архитектурная ошибка?
Есть
Но это уже немного из другой оперы.
Из оперы про то, что на стороне " один " должен быть уникальный индекс по обязательному полю / комбинации обязательных полей.
Или же аксес должен по другому обрабатывать Null в уникальных индексах.

2 *
Знаю, знаю, не спорю.
Ты про логику проверки - я про возможность получения связи многие-ко-многим вместо один-ко-многим.

2 Раз (1)
В MS SQL уникальный индекс по необязательному полю не может содержать несколько записей со значением Null - будет нарушение уникальности. Где MS SQL находит нарушение - мне непонятно, ибо в таблице отсутствуют записи, в которых индексированные поля совпадали бы (ибо Null не равен ничему, в том числе и другому Null'у)
В аксесе уникальный индекс по необязательному полю может содержать несколько Null'ов. Что само по себе и неплохо, но в сочетании с проверкой частично заполненного FK - дает то самое грубое архитектурное нарушение.

Вдогонку

2 *
*2 йййй
Уникальность ключа на стороне "один" естественно предполагается (без этого не создашь FK).
Уникальность - предполагается
Однако я писал:
авторчто на стороне "один" должен быть уникальный индекс по обязательному полю / комбинации обязательных полей.

2. на стороне "один" обязательность заполнения не требуется системой и если ее нет, приходим к странному
Да и я, в общем-то, о том же. Либо обязательность, либо не проверять ссылки для частично заполненного FK (и не выполнять всякие там каскадные обновления/удаления), либо получим бред.

Алё, гараж??? Ctrl-G нажмите

ээээ
незаметил что вы из плоскости скуля ушли