- ベストアンサー
アクセスデータベースのUnicode圧縮について
Access2000のメモ型へ4096バイト以下のデータ(約3KB)書き込みを行いましたが、Unicode圧縮がうまく動作していないようでＤＢサイズが想定の約２倍以上になりました。フィールドプロパティのUnicode圧縮は、「はい」としているのですが、その他に何か処理が必要でしょうか？、また、Unicode圧縮がうまく動作しているか確認する方法があれば教えて下さい。OSはWin2000です。
- yarazu
- お礼率62% (17/27)
- その他(データベース)
- 回答数4
- ありがとう数3
- みんなの回答 （4）
- 専門家の回答
質問者が選んだベストアンサー
ファイルサイズを気にしていらっしゃるのかなと思って前回の回答を したのですが、純粋に Unicode 圧縮の確認ということなんですね。 読み違いで失礼しました。 Unicode 圧縮されているかどうかは、MDB ファイルをバイナリエディタで 開けば簡単に確認できます。 ちなみに私が WinXP SP-2 + Access 2003 SP-2 で確認した限りでは、 データが ASCII で 32 バイトを超えると、Unicode 圧縮はされていない ようでした。 これは Microsoft の公表している仕様と明らかに矛盾しますが、私は この現象について説明する手段を持ちません。 MS に直接訊くしかないかもしれないという気もします。
その他の回答 (3)
- yu_tang
- ベストアンサー率81% (26/32)
Access 2000（Jet 4.0）以降は、レコードレベルロックが有効になって いると急激にファイルサイズが肥大化することで知られています。 ※ 参考 URL「7. MDB の巨大化に要注意」を参照のこと。 レコードレベルロックをオフにしてから最適化して、ファイルサイズが 小さくなるようであれば、Unicode 圧縮とは無関係と考えてよいと思い ます。 ただし、その場合でも、レコードレベルロックをオフで運用するのが 妥当かどうかは、状況に応じてご自身で判断してください。 レコードレベルロックをオフにするとファイルサイズは抑えられますが、 MDB を共有している場合はトレードオフでセッション競合の発生率が 高くなります。
補足
回答ありがとうございます。当方ＤＢ初心者でAccessDBに書込/読込が出来るかどうかの試験をしている程度です。メモ型のフィールドに6MBのデータを書き込んだ際、予想以上にDBサイズが膨らんだ為、6MBを4KB程度に分割書き込みしてUnicode圧縮の効果を確認しようとしましたが、その効果が確認できなかったため、質問させて頂いた次第です。
- O_cyan
- ベストアンサー率59% (745/1260)
>"最適化"は既に行っています Access2000以降のバージョンでは以前のバージョンと違いUnicodeは文字を2バイトで表現していますよね。テキスト型やメモ型などのフィールドにデータを格納するのにAccess97以前のバージョンより大きな領域を必要とします。 Unicodeではサポートされる任意の文字の組み合わせを１つのフィールドに記述できますが最初のバイトが0でない文字は圧縮の効果はありません。メモ型フィールドの内容が圧縮されるかどうかはレコードによって異なります。 最適化してもサイズが変わらなければそれが最小のサイズとなります。
お礼
遅くなりましたが、回答ありがとうございました。無事、Unicode圧縮を確認することが出来ました。
補足
何度もありがとうございます。メモ型への格納データは、半角英数字のみとしています。この為、フィールドの最初のバイトが０になり圧縮できるものと考えています。 >最適化してもサイズが変わらなければそれが最小のサイズとなります。 確かに、最適化して小さくならないのですから、現状のＤＢがその領域分使用していると考えています。Unicode圧縮が反映できていない様なので、その確認方法または反映の為の手法をアドバイス頂ければ助かります。
- O_cyan
- ベストアンサー率59% (745/1260)
メニューのツールにあるデータベースユーティリティの[データベースの最適化/修復]をしてください。 膨れ上がったサイズが最適化され減ります。
補足
回答ありがとうございます。"最適化"は既に行っています。最適化後のサイズでUnicode圧縮が行われていないように感じています。
お礼
遅くなりましたが、回答ありがとうございました。無事、Unicode圧縮を確認することが出来ました。ファイルサイズは期待した程小さくならないようですね。
補足
何度もありがとうございます。ＤＢへの先入観か、バイナリーエディタは思いつきませんでした。で、確認できた内容を補足します。64BYTEで確認すると64BYTEの圧縮結果とゴミのような32BYTE相当のUnicodeが格納されていました。ゴミのようなエリアは、最適化では消滅しませんでしたが、追加書き込みすると消滅していました。圧縮時の作業エリアが少し残るようですが、1024BYTEまでは圧縮結果を確認することが出来ました。ただ、2048BYTEではダメな様です。もう少し勉強します。