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

Question

У меня есть tblUsers, у которого есть первичный ключ UserID.

UserID используется как внешний ключ во многих таблицах. В таблице он используется как внешний ключ для нескольких полей (например, ObserverID, RecorderID, CheckerID).

Я успешно добавил отношения (в представлении MS Access «Отношения»), где у меня есть псевдонимы таблиц для выполнения нескольких отношений на таблицу:

* tblUser.UserID -> 1 ко многим -> tblResight.ObserverID

* tblUser_1.UserID -> 1 ко многим -> tblResight.CheckerID

После создания примерно 25 отношений с применением ссылочной целостности при попытке добавить дополнительную я получаю следующую ошибку:

"Операция завершилась неудачно. Слишком много индексов в таблице 'tblUsers.' Удалите некоторые индексы в таблице и повторите операцию. "

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

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

Answer 1

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

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

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

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

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

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

Answer 4

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

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

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