現象
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で変なデータが紛れたのか、主キーなのに長さが違うデータが混在してエラーとなったのが原因なのでしょうかね？
同じ悩みをお持ちでここにたどり着き、多くの方が解決して頂ければ幸いです。