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

Question

Я надеюсь, что кто-то может помочь мне с этим:

У меня есть простой запрос, сочетающий в себе список имен и базовых детали с другой таблицей, содержащей более конкретной информацией. Некоторые имена обязательно появятся более одного раза, и произвольные различия, такие как «John Smith 1» и «John Smith 2», не являются опцией, поэтому я использую autonumber для записи записей.

Проблема в том, что мой запрос создает две записи для каждого имени, которое появляется более одного раза. Например, есть два клиента с именем «Sophoan», каждый с другим номером идентификатора, и запрос подбирает каждый из них дважды, что приводит к четырем записям (всего 122 записи, когда их должно быть только 102). «Уникальные значения» установлены на «да».

Я исследовал как можно больше и полностью застрял. Я пытался возиться с sql, но он всегда возвращается с ошибками, я полагаю, потому что в запросе слишком много полей.

Что мне не хватает? Или это неправильный подход, и мне нужно найти другой способ объединить мои таблицы?

Проект в деталях: Я создаю базу данных для благотворительности, которая имеет два основных вида деятельности: социальная работа и обучение. База данных предназначена для записи информации о клиентах и ​​результатов их взаимодействия с клиентами (вопросы, которые они просили о помощи, результаты учебных семинаров и т. Д.). Некоторые клиенты будут переходить между мероприятиями, которые организация хочет отслеживать, следовательно, все зарегистрированные клиенты входят в один список и отдельные таблицы, которые собирают данные для каждой конкретной деятельности, в которой участвует клиент. Этот запрос должен быть моим решением для объединяя эти таблицы для ввода данных пользователем.

В настоящее время у меня есть следующие таблицы:

• AllList (мастер список имен клиентов и основной контактной информации, «Социальная работа Регистрация» и «Участник Регистрация» присоединиться к этой таблице по «Name»)
• Социальная работа Регистрация (список клиентов социальной работы с полной информацией каждого случая)
• социальной работы Последующая таблица (используется, когда сотрудники называют клиентов социальной работы , чтобы увидеть, как их проблема прогрессирует, регистр имеет слишком много колонок, чтобы удерживать это; присоединился к Регистрация по «Имя клиента»)
• Участники Регистрация (список клиентов для обучения и деталей практикумам они присутствовали и почему они отсутствовали, если они пропустил сеанс)
• Индивидуальный семинар таблицы x14 (каждый семинар включает в себя тест и в этих таблицах приведены ответы клиентов и их оценка для каждого отдельного теста , при этом будет завершена работа с базой данных , все присоединились к «Регистру участников» на «Имя участника»,)

Запросов:

• Участник Обзор запросы (связывают данные о посещаемости из «Регистра» с сортировочными данными от каждого семинара представить только для чтения обзора; этот, кажется, работает отлично)
• Запрос социальной работы (не функциональный, предназначенный для связи «Клиент Зарегистрируйтесь» в «AllList» для ввода данных, чтобы при регистрации нового клиента
  он создает новую запись в обеих таблицах, с
  записей совпавших вместе)
• Участник запроса (еще не пытались, как указано выше, предназначены для соединения «участника Регистрация» к «AllList» для ввода данных)

НО Я понял, что запросы могут ' t для ввода данных, поэтому этот подход кажется тупиковым. У меня был некоторый успех с использованием подформ для ввода данных, но я не уверен, что это лучший способ.

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

[N.B. Есть несколько таблиц, которые хранят вторичную информацию, но не относятся к этому вопросу, поскольку они не являются и не будут связаны с любыми другими таблицами.]

Answer 1

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

на самом деле, не сложные запросы являются обычно редактируемые до тех пор, как таблицы, данные, которые вы хотите редактировать остатки «в центре» запроса.Доступ использует ряд факторов, чтобы определить, доступен ли запрос для редактирования или нет.
В большинстве случаев довольно легко понять, почему запрос стал недоступным для редактирования.
Задайте себе вопрос: если я отредактирую эти данные, как Access будет гарантировать, что именно эти данные будут обновлены без двусмысленности?

Если в ваших таблицах определены первичные ключи, и это часть вашего запроса, и если нет группировки, вычисленных полей (полей, которые используют какую-либо функцию для изменения или проверки значения этого поля) или сложных объединений, то запрос должен оставаться редактируемым.
Вы можете прочитать больше о том, что здесь:

• How to troubleshoot errors that may occur when you update data in Access queries and in Access forms
• Dealing with Non-Updateable Microsoft Access Queries and the Use of Temporary Tables.

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

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

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

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

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

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

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

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

В этом случае создайте поле ClientID Number (внешний ключ), в котором будет храниться связанный Клиент ID в таблице ClientCase.

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

• Не более 1 Case? (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 запросов, которые вы пробовали. Из описания, которое вы даете, трудно понять реальные детали дизайна и рассказать вам, почему он не работает, и как заставить его работать.