現象

AccessからODBCを介してSQL Serverのテーブルをリンクして使っていた所、一部のユーザーが「#Deleted」と表示されるようになりました。
開発機では現象出ず、他ユーザーでも正常に使える人とそうでない人が混在しており、益々原因不明です。

ネットで調べると・・・

１. パススルークエリを使うと回避出来る
この方法を使うと、確かにAccess側から参照しても正常に見えるようになりました。
しかし、根本的解決に至ってない気がして何かもやもやします。
現象発生するテーブルのみパススルークエリにするのもいまいち抵抗感がありました。

２. SQL Server側でbigintを使っている
SQL Server側でbigintを使っている事が原因であり、下記の方法で解決するとの事。

方法１. SQL Server側をintに修正、Access側を再リンク
方法２. Access側のオプション→現在のデータベース→データ型のサポートオプションの「リンク/インポートされたテーブルで大きい数値(BigInt)データ型をサポート」にチェックを入れ、Accessを再起動

しかし、今回の環境のテーブルにはBigIntは使っていませんでした。

３. DateTime型にて小数点が使われている。
SQL Server側でDateTime型の秒データにて、小数点以下のデータが存在している事が原因であり、下記の方法で解決するとの事。

方法１. 更新クエリを使い、小数点以下のデータを丸める。
方法２. SQL Server側をsmallDateTimeに修正、Access側を再リンク
方法３. Access側のオプション→現在のデータベース→データ型のサポートオプションの「リンク/インポートされたテーブルの拡張日時(DateTime2)データ型のサポート」にチェックを入れ、Accessを再起動

DateTimeフィールドが存在していたので、SQL Server側の該当フィールドをsmallDateTime型に変更、再リンクしてみましたが、解決しませんでした。
ダメ元で「拡張日時(DateTime2)データ型のサポート」にチェックを入れてみましたが解決しません。

考察

上記「2. SQL Server側でbigintを使っている」関連で、色々調べていると PK（プライマリキー？） にbigintを使っているとダメ 、みたいな記述を発見しました。
これを見て、主キーのフィールドが関係しているのではないかと思いました。
このテーブルの主キーは６桁固定の英数字で構成されるコードです。

フィールドの型を見てみると、何故か nvarchr(10) となっておりました。
char型に於いて、違いを調べると下記のような用途との事です。

char → ASCII 固定長
nchar → UNICODE 固定長
varchar → ASCII 可変長
nvarchar → UNICODE 可変長

今回のフィールドは「２バイト文字を含む10バイトまでの可変長」という事になります。
仕様としては６桁固定であり、コードに２バイト文字（漢字等）を使うことはあり得ないので、 char(6) としてみました。

すると、上手く行きました。

原因と対策

今回の原因は 主キーフィールドの型がUNICODE 可変長であった事 であり、
ASCII 固定長 にする事によって解決しました。

UNICODEで変なデータが紛れたのか、主キーなのに長さが違うデータが混在してエラーとなったのが原因なのでしょうかね？

同じ悩みをお持ちでここにたどり着き、多くの方が解決して頂ければ幸いです。