There is a data type problem.
You do not say what type of DB you are importing from.
Every table in SQL Server should always have a PK and a timestamp field in
order to interact best with Access.
The timestamp is a data type, but it is not Date/Time!!
The timestamp is changed to a unique value whenever a row is modified.
If you add it to the table, then Access will use it "silently" to check to
see if anyone has changed the record since it was downloaded. (In other
words, the timestamp field does not need to be part of the SELECT
statement.)
Access compares the timestamp it downloaded to the current one and then
allows the update.
When there is no timestamp field, Access has to check *every* field in that
row to see if the data has changed. Not only is this slow, it often fails
due to decimal data type inaccuracies.
Also, check your table to see if you have a boolean field that is type
"Bit". If you have any Bit fields, they MUST have a default value and MUST
NOT be null.
See the following MS KB article:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;278696
For a Microsoft Access 2000 version of this article, see:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;280730
================================================================
You can create a "Fake" index in Access that tells Access which columns make
a Unique record in the linked table. The index is only used by Access is
completely unknown to the Server.
The following example creates an index on an ODBC linked table. The table's
remote database is unaware of and unaffected by the new index. The following
example won't work if you simply paste it into Microsoft Access; you first
need to create an ODBC linked table called OrderDetailsODBC.
(CREATE INDEX Statement in Help has some examples)
CREATE UNIQUE INDEX OrderID ON OrderDetailsODBC (OrderID);