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

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

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

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

*tblUser.UserID - > 1 для многих -> tblResight.ObserverID

*tblUser_1.UserID - > 1 для многих - > tblResight.CheckerID

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

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

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

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

7
indexing ms-access relationship

4 ответов

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

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

все snipets код и все Я нашел через google, вернулся, что у меня было шесть индексов на столе (и, следовательно, я запутался). Чего я не находил/не знал, так это того, что мои 25 отношений были подсчитаны против моих 32, потому что я был принужден.

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

в принципе, это еще одна причина, по которой я мигрирую из access и в PostgreSQL в ближайшее время.

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

8

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

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

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

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

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

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

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

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

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

0

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

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

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

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

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

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

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

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

0