Запрос доступа дублирует уникальные записи/проблемы со связанной таблицей

Итак, что я в основном надеюсь достичь, так это способ одновременного ввода одних и тех же данных в две таблицы (для новых записей) и сопоставления полученных записей (для новых записей с существующими записями). Но должна быть возможность, чтобы одно и то же имя появлялось более одного раза в виде уникальной записи (например, три человека по имени Джон Смит).

Это замечание на самом деле доказывает, что у вас есть проблемы с дизайном вашей базы данных.

Основным принципом проектирования баз данных является максимально возможное устранение избыточности. Одна из причин заключается в том, чтобы избежать необходимости обновлять одни и те же данные в нескольких местах.

Еще одно замечание: вы используете имя Клиента в качестве Естественного ключа. Честно говоря, это не очень хорошая идея. Как правило, вы хотите убедиться, что то, что представляет собой первичный ключ для таблицы, будет надежно уникальным с течением времени.
Использование имен людей, как правило, является неправильным выбором, потому что:

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

Лучший способ обеспечить уникальность записей в таблице — использовать поле AutoNumber ID по умолчанию, предложенное Access при создании новой таблицы. Это называется Суррогатный ключ.
Его нельзя редактировать, изменять или даже показывать пользователю. Его единственная цель — сделать первичный ключ таблицы уникальным и неизменяемым с течением времени, чтобы его можно было надежно использовать в качестве способа ссылки на запись из одной таблицы в другую (если таблица должна ссылаться на конкретную запись, она будет содержать поле, которое будет содержать этот ID. Это поле называется Внешний ключ).

Имена, которые у вас есть для ваших таблиц, недостаточно точны: думайте о каждой таблице как о сущности, содержащей связанные данные.
Тот факт, что у вас есть таблица с именем AllList, означает, что ее назначение не в этом. хорошо продуманный; это звучит как всеобъемлющее, а не как тщательно продуманная сущность.
Вместо этого, если это ваш список клиентов, просто назовите его Client. Каждая запись в этой таблице содержит информацию для одного клиента (использовать множественное или единственное число зависит от вас, просто придерживайтесь своего выбора, чрезвычайно важно быть последовательным).
Вместо использования имени клиента в качестве ключа , создайте поле ID, автонумерацию и установите его как первичный ключ.

Давайте также переименуем «Реестр социальной работы», в котором хранятся дела Клиента, просто как ClientCase. Эта взаимосвязь кажется очевидной из вашего описания таблицы, но неясна в самом имени таблицы (кстати, я знаю, что Access допускает пробелы в именах таблиц и полей, но это очень плохая идея использовать их, если вы заботитесь хотя бы о немного о будущем вашей работы).

При этом создайте числовое поле ClientID (внешний ключ), которое будет содержать ID соответствующего клиента в таблице ClientCase.

Вы не говорите об отношениях между Клиентом и его Делами. Это еще одна область, где вы должны быть ясны: сколько дел может иметь один клиент?

• Не более 1 случая? (0 или 1 случай)
• ровно 1 случай?
• хоть один кейс? (1 или более дел)
• любое количество случаев? (0 или более дел)

Знание этого важно для выбора правильного типа JOIN в ваших запросах. Это важная часть предположений о дизайне при создании базы данных.

Например, в самом общем случае, предполагая, что у клиента может быть 0 или более обращений, у вас может быть отчет, отображающий имя клиента и количество связанных с ним обращений, например:

SELECT Client.Name,
       Count(ClientCase.ID) AS CountOfCases
FROM Client
  LEFT JOIN ClientCase
     ON Client.ID = ClienCase.ClientID
GROUP BY Client.Name

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