Access Audit Inspection + History block!

Question

Задача:

 - электронная форма, которая отображает 45 контрольных точек (редко меняется)
- 3 дополнительных столбца
  - Рейтинг (0, 1, 2)
  - Корректирующее действие (Немедленно, СОП, WO)
  - Заметки
- Вести историю проверок
  - дата проверки, проверена производственная линия, проверена сменная бригада 

Таблицы:

 - Сотрудник (empID (auto#), FName, LName, Shift, Line)
- Факты аудита (ID#, textdescrip) пробовали с и без автонумерации
- Подробности аудита (auditID (auto#), auddate, рейтинг, действие, заметки)  *(комбинированный список рейтинга / действия) 

Подформа в форме имеет 45 контрольных точек, все они привязаны к номеру аудита. Тем не менее, я не могу получить результаты аудита для записи, хранения и перемещения в историю.

каждая попытка, которую я сделал, производит номер проверки PER каждые 45 проверок, в отличие от

 Audit Date
   AuditID(auto#)
      AuditFact (list of 45 chckpts)

Результаты

        Audit1, 10/02/2010 ->
           *AuditPt     Rate     Action*        
                IF1          0      WO
                IF2          2 СОП... 
                IF45         1 Немедленно

        Аудит2, 15.12.2010 ->
           *AuditPt     Rate     Action*        
                IF1          1      WO
                IF2          0 СОП... 
                IF45         0 Немедленно 

Answer 1

Приведите свои таблицы в порядок, и ваши формы будут следовать.

Исходный вопрос не совсем ясен, но я думаю, что я получил эти очки:

1. "Аудит" - это то же самое, что "Инспекция"
2. Набор из 45 "инспекционных пунктов" представляет собой аудит (не каждый в отдельности).
3. "Рейтинги" и "Действия" применяются к каждой точке контроля.

Таким образом, ваши таблицы хотят быть похожими на это:

Audit
  AuditId (can be autonumber, or not...)
  AuditDate

AuditItem
  AuditItemId (can be autonumber, or not...)
  AuditId (FK from Audit)
  InspPoint (e.g., the "IF1" from the "result" sample, or--better--an FK to it another table)
  Rating
  Action (Or--better--an FK to it another table)

Таблица "Сотрудник" кажется совершенно не относящейся к этой структуре.

Обратите внимание, что у каждой точки пересечения есть своя собственная строка в AuditItem для каждого аудита, и что эти строки также содержат AuditID из Audit, что позволяет объединить их все для вывода результатов.

Надеюсь, это будет иметь смысл - если это не так, я рекомендую рассмотреть фундаментальный дизайн реляционной базы данных.