ACC2000: Access May Choose an Unexpected Index as the Primary KeyID: Q207745
|
When you link a table from an ODBC data source, such as Microsoft SQL Server or ORACLE, and that table contains more than one unique index, Microsoft Access may select the wrong index as the primary key.
When you link a table from an ODBC data source, the Microsoft Jet database
engine makes a call to SQLStatistics, an ODBC API function used to identify the first unique index to select as the primary key. SQLStatistics returns index information in the following order: Clustered, Hashed, Non-clustered, or other indexes. In addition, each index is listed alphabetically within each group.
NOTE: All indexes created within ORACLE are treated as non-clustered indexes. Therefore, the order of the index is determined by the name, rather than by the type.
To ensure that the Jet database engine properly selects the desired index
as the primary key when linking the table from your ODBC backend, you can
rename the index so that it appears first alphabetically.
NOTE: When using SQL Server version 6.x, this behavior only occurs if you are using non-clustered unique indexes.
CREATE TABLE tblPKTest
(
ID int Primary Key Nonclustered,
Fname varchar(50) null,
Lname varchar(50) null,
Field3 varchar(50) null
)
go
CREATE UNIQUE INDEX aaa on tblPKTest(Fname,Lname)
The third-party products discussed here are manufactured by vendors
independent of Microsoft; we make no warranty, implied or otherwise,
regarding these products' performance or reliability.
Additional query words: indexes
Keywords : kb3rdparty kbdta OdbcProb
Version : WINDOWS:2000
Platform : WINDOWS
Issue type : kbprb
Last Reviewed: May 13, 1999