Слишком много индексов для ошибки таблицы при создании отношений в Microsoft Access 2010

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

Каждая таблица может иметь только 32 «ограничения». Каждый индекс и обеспечение ссылочной целостности (RI) учитываются в этом 32. MS Access автоматически создает ограничение, когда вы выбираете принудительное выполнение RI; вы не можете отключить эту опцию.

Все фрагменты кода и вещи, которые я нашел через Google, вернули, что у меня есть шесть индексов в таблице (и, следовательно, я запутался). Чего я не обнаружил/не знал, так это того, что мои 25 отношений были засчитаны против моих 32, потому что у меня был принудительный RI.

Мое решение состояло в том, чтобы удалить RI для полей с «более низким приоритетом» (мне больно это говорить) и «принудительно применять» его через формы ввода данных.

По сути, это еще одна причина, по которой я скоро перенесу Access на PostgreSQL.

Если у кого-то есть лучшая работа, я хотел бы здесь. Спасибо.

В вашей таблице есть скрытые индексы, созданные при определении отношений. Имена скрытых индексов начинаются с символа «~». Но код, который вы нашли, игнорирует скрытые индексы из-за этого выражения:

If Left(tbl.Name, 4) <> "MSys" And Left(tbl.Name, 1) <> "~" Then

Вы можете сделать так, чтобы функция ListIndexes() включала скрытые индексы, изменив эту строку на эту:

If Left(tbl.Name, 4) <> "MSys" Then

Кроме того, вы можете проверить общее количество индексов для вашей таблицы с помощью этого оператора в окне Immediate:

? CurrentDb.TableDefs("tblUsers").Indexes.Count

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

Sub TableListIndexes(sTableName As String, Optional bPrintFields As Boolean = False)

    'Print indexes on a table, and fields in each index.
    'Need to add a reference to Microsoft ADO Ext. [version] for DDL and Security (ADOX).

    Dim cat As New ADOX.Catalog
    Dim idxs As ADOX.Indexes
    Dim idx As ADOX.Index
    Dim col As ADOX.Column
    Dim i As Integer

    Set cat.ActiveConnection = CurrentProject.Connection
    Set idxs = cat.Tables(sTableName).Indexes
    For Each idx In idxs
        Debug.Print i, idx.Name
        If bPrintFields Then
            For Each col In idx.Columns
                Debug.Print , col
            Next
        End If
        i = i + 1
    Next

End Sub

Sub TestTableListIndexes()
    TableListIndexes "tblProject"
End Sub

Который дает

0            PrimaryKey  
1            ProjectBusinessUnitID_6D55FF7827CC48648A15A8E576EF02EF  
2            ProjectDivisionID_9CAC7B9D8136467B97F9BAA7217EAC38
etc

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

Она довольно старая, но проблема возникает очень часто, и эта ветка стоит на первом месте в поисковых машинах (мне кто-то сказал ;))

Хорошей возможностью решить эту проблему является работа с «вспомогательной таблицей» для связи с другими таблицами.

Пример: таблица Article по разным причинам связана со многими другими таблицами. Также ей может понадобиться много внешних ключей для себя. Такие таблицы очень часто попадают за пределы возможных индексов. У меня также есть три или четыре из них в моих самых больших проектах.

Чтобы почти удвоить количество возможных соединений/индексов RI, вы можете работать со вспомогательной таблицей, которая имеет соединение RI 1:1 с таблицей tblArticle только с уникальным идентификатором в качестве поля. Я называю его так же, но не с короткой буквой fk перед ним, как обычно. Назовем его tblArticleLinker.

Каждая таблица, которая получает внешний ключ от tblArticle, например Order-Position, получает соединение от tblArticleLinker. --> Вы не потеряете индекс для всех этих ссылок, только одну ссылку на Linkertable

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

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

Совет: Тот же подход можно использовать и для того, чтобы пользователь мог использовать только «выпущенные» записи. Или просто использовать в качестве жесткого фильтра. Это помогает преодолеть возможные программные ошибки, которые не следуют логике, которой должны.