ACCESS総合相談所その１６【桐にしとけ】

ACCESS総合相談所その１６【桐にしとけ】 at BSOFT

915:名無しさん＠そうだ選挙にいこう
07/03/23 21:43:42
>>908
それ当然

916:913
07/03/23 21:56:39
とりあえず解決しますた。フォームのレコードソースに ORDER BY ID とつけたら ID 順になりますた。
はじめは ORDER BY A.ID というように別名付きで書いていたからだめだったみたい。

917:名無しさん＠そうだ選挙にいこう
07/03/23 22:26:07
>>908
こういう話を聞くとACCESS2000のMDB内部は本当にUNICODEで
データ格納してるんだって実感できるな。

918:名無しさん＠そうだ選挙にいこう
07/03/23 22:32:25
何の為にフィールドサイズを設定するのかと小一時間
桐だとテキストフォールドは可変長だけどな

919:名無しさん＠そうだ選挙にいこう
07/03/23 22:39:56
918がどれに対するレスなのか知らんが
Accessのフィールドサイズは文字数で、
バイト数ではないよ。

920:名無しさん＠そうだ選挙にいこう
07/03/24 01:30:45
>>918
Accessも可変長で格納してます。一応、定義として最大文字数を設定する
礼儀と考えれば良いかと・・・。

921:名無しさん＠そうだ選挙にいこう
07/03/24 06:13:56
>>908
マルチユーザーによる同時アクセスが絶対に無い（バックエンドDBだったりしない）
のであれば、ツール-オプション-詳細タブの「レコードレベルでロックして開く」を
オフにしてから最適化してみる。

ちなみに、英文字のみであればUnicode圧縮（既定でオン）が効くので、単純に倍に
なったりはしないはず（オフであれば当然ASCII/SJISの倍）。

AccessのGUIから作成したテキスト型であれば、フィールドサイズを削っても、
>920 さんの指摘どおり、容量削減の観点からは無意味。

922:名無しさん＠そうだ選挙にいこう
07/03/24 09:03:27
アクセスのフィールドサイズってハッタリかよ藁

923:名無しさん＠そうだ選挙にいこう
07/03/24 09:36:48
>>922
設定した文字数制限ができるからハッタリまでは落ちぶれてないよ。
バイト数じゃなくなったので非常に使いづらいけど。

924:908
07/03/24 09:56:05
>921
この回答を見たときに小躍りしながら試してみました。
「レコードレベルでロック」＞すでにチェック入り
一度テキストに出力しレコード定義にUnicode圧縮を設定してから取り込み直し＞ほとんど変わらない

>912さんのお察しの通り内容はほとんど１バイト英数文字です。
内部がUnicodeとは言えさすがに全部の文字に２バイトずつ割り当てないだろうと
思っていましたがどうやら甘かった様ですね・・・・。

925:921
07/03/24 11:31:29
>>924
おはようございます。

> 「レコードレベルでロック」＞すでにチェック入り

えーと、一応確認ですけど、チェック入りだったからチェックを
外して最適化した、という意味でおｋ？

926:921
07/03/24 12:59:40
情報追加。
URLﾘﾝｸ(support.microsoft.com)
関係なかったらｽﾏｿ

927:908
07/03/26 10:10:59
>925
焦ってて書き方がおかしかったですね
「レコードレベルでロックのチェックボックスを外すのはチェック済み」です
>>926を見る限りUnicode圧縮の設定のON/OFFで容量が変わるはずなのに
ほとんど変わらないのが気に掛かってます
ちょっと別の環境で同じ処理を試してみます

928:908
07/03/26 16:57:24
Unicode圧縮有りでテーブルを再定義しでデータを追加し直ししてみましたが変わらず
MDBファイルをバイナリエディタで開いてみたんですがフィールド内容と思われるACSII文字列に
しっかり00が付加されてました（１バイトごとに）
圧縮かかってないですよね、これ

929:908
07/03/26 19:51:18
Unicode圧縮がかからない点から調べて引っかかった情報
URLﾘﾝｸ(oshiete1.goo.ne.jp)
これはメモ型の話みたいですがテキスト型にも影響があるんでしょうか？

930:名無しさん＠そうだ選挙にいこう
07/03/27 23:50:16

URLﾘﾝｸ(www2.moug.net)

>Excelで開くと決まった位置にデータが並んでいるので、セル位置として指定
>しやすいからという理由です。

>>わざわざExcelを使う必要はないと思います。

>逆にわざわざExcelを使わない必要はあるのでしょうか？

これってどうなん?
俺は素人さんがcsvの中身を確認できるように
Accessに取り込んでExcelにエクスポートしているが。
つうか、絶対開くなと言っているのだが。

931:921
07/03/28 01:21:12
ちょっとAccess 2003でテストしてみた。

空のMDBを作成し、そこに英数字のみ32文字×1万行のCSV（ASCIIで保存）を
新規テーブルとしてインポート（当然テキスト型フィールド）。

1. インポート前のdb1.mdbのサイズ
　 →96.0kb(98,308byte)
　インポート前のtest.csvのサイズ
　 →332kb(340,000byte)

2. test.csvをインポート直後のdb1.mdbのサイズ
　 →900kb(921,600byte)
　 ※1フィールドのみ、インデックスなし、Unicode圧縮なし

3. 2の状態からそのまま最適化した直後のdb1.mdbのサイズ
　 →908kb(929,792byte)

932:921
07/03/28 01:23:20
4. 2の状態からUnicode圧縮を「はい」にして最適化した直後のdb1.mdbのサイズ
　 →588kb(602,112byte)

5. 4の状態から[レコードレベルでロックして開く]をオフにして最適化した直後のdb1.mdbのサイズ
　 →588KB(602,112byte)

結論。
このテストに限れば、[レコードレベルでロックして開く]は容量と関係なかった。
スマン。

単純に考えるとUnicode圧縮なしで元ファイルの２倍、有りだと１倍で済む
ような気がするかもしれないが、実際はUnicode圧縮なしで３倍近く、圧縮
ありでやっと約２倍に抑えられている模様。

なんかいろいろやってるんでしょう、としか自分には言えません。w

なお、バイナリエディタで確認してみたけど、Unicode圧縮後はちゃんと
ASCIIになってました（00なしの1バイトで格納されてた）。

933:908
07/03/28 09:34:16
Unicode圧縮が出来るケースと出来ないケースがあることを確認しています
メモ型で4K以上は出来ないとありましたがそれ以外にも何かありそうです
まだ原因を絞り込めてないのですが20万件の同じデータ（並び順だけ違う）を
使用して出来た場合と出来なかった場合で今の時点発見している違いは

・ファイルが違う
　（片方は他テーブル有りで圧縮がかかっていなかったファイル
　　成功したのはテーブル構造をコピーして単独のテーブルに切り分けしたファイル）
・インデックスの指定の有無（成功した方には無かった）
・空文字を許可しているかいないか（成功した方は許可、実際に空のデータ有り）

レコードでは無く項目を削るとUnicode圧縮が出来たのを確認したんで
徐々に調整しつつ項目を増やしていったのですが全部Unicode圧縮がかかるファイルと
かからないファイルが出来てしまいました
ファイル側で何か要因があるんでしょうか・・・

934:名無しさん＠そうだ選挙にいこう
07/03/29 00:57:47
アクセス９７　にSR-2を当てタイのですが、
SR-2のダウンロード先ありますか？

935:名無しさん＠そうだ選挙にいこう
07/03/29 02:30:25
>>934
検索汁
URLﾘﾝｸ(office.microsoft.com)