Access2003でインポートするとクエリが壊れる場合がある
	Access2003で他のmdbからすべてのオブジェクトをインポートするとクエリが壊れる場合があります。問題のmdbと弊社で確認している現象は次のとおりです。
		インポート元mdb
			サイズ：2,876Kb(コンパイル、最適化後) テーブル数：8 リンクテーブル数：45 クエリ数：70 フォーム数：30 レポート数：15 マクロ数：2 モジュール数：7
		現象
			１．一部のクエリーで結合線が消える ２．一部のクエリーで抽出条件欄に記述したユーザ関数が消える
		回避方法
			モジュールとモジュール以外(テーブル・クエリ・フォーム・フォーム・レポート・マクロ)のオブジェクトを別々にインポートします。弊社では最初にモジュール以外のオブジェクトをインポートし、次にモジュールをインポートしています。 ＊このmdb以外では再現していません。もし同様の現象が出た場合はお試しください。
	（UPD:04/10/28）
		追加情報
			リンクを削除してインポートすると、テーブルの存在をチェックするというMS恒例のおせっかいのせいで、クエリがズタズタなります。
	（UPD:05/11/06）
			システムアート研究所　中西 健 様から次の情報をいただきました。 　あれから当方独自に調査した結果、「名前の自動修正情報をトラックする」のチェックを外せば該当の現象が起こらないらしいということがわかりました。 　うかつでした！新しい機能のことはすっかり忘れていました。
	（UPD:06/02/03）
Access2000の「PostalAddress/住所入力支援」をWindowsXP（IME2002)で動かすとふりがなで不具合
	Access2000 + windowsXP（IME2002） の環境で「PostalAddress/住所入力支援」を動かすと「FuriganaControl/ふりがな」プロパティに設定されたテキストボックスには郵便番号が表示されてしまいます。
	Access2000 + windowsMe（IME2000） の環境では、「FuriganaControl/ふりがな」プロパティに設定されたテキストボックスには正常にフリガナが表示されます。もちろんAccess2002 + windowsXP（IME2002）の環境でも正常に表示されます。
	MSには確認していませんが、開発元のアドバンスソフトウェア株式会社（アドバンス技研株式会社）（福井市）のせいにしたりして・・・・
	（UPD:03/07/11）
VBAでDir関数に２６０バイト以上のパス名を指定すると「ファイルが見つかりません」のエラー
	Access97、Excel97
		Dir関数に２６１バイト以上のパス名を指定すると「ファイルが見つかりません」のエラーが発生します。
	Access2000、Excel2000、Excel2002、VB6.0
		Dir関数に２６０バイト以上のパス名を指定すると「ファイルが見つかりません」のエラーが発生します。
	サンプルコード
		Sub DirTest() 　Dim w As String 　Dim i As Integer 　w = "c:\" 　For i = 1 To 12 　　w = w & "１２３４５６７８９０" 　Next i 　w = w & "12345678901234.txt" 　MsgBox LenB(StrConv(w, vbFromUnicode)) 　MsgBox Dir$(w) 'ここでエラー発生 　Debug.Print w End Sub
	ファイルの存在チェックにDir関数を使うのは危険です。ぜひ PathFileExists を使いましょう。 WindowXPはどうしてもフォルダ階層が深いので、260バイトを超える階層のファイルリストを取るにはどうすればいいんでしょうね？MSさん
	（UPD:02/06/22）

Windows XPでのFormat関数の扱い
	まず、Windows ＸＰでのＦｏｒｍａｔ関数についてのＭＳのページを参照してください。
		Windows XP 上での Format 関数の動作について 最終更新日: 2002/02/13 文書番号: J070082 この資料は以下の製品について記述したものです。 Microsoft Visual Basic 6.0
	製品をＶＢに限定してますが、当然ＶＢＡでも同様の現象が発生します。 要約すればWindows XPから、Ｆｏｒｍａｔ関数の丸め方法が変わったと言うことなのですが まずＥｘｃｅｌでの例
		Ａ列：値を入力し書式設定は標準 Ｂ列：Ａ列の値を参照し、書式 -1,234 少数以下０桁に設定　→正常 Ｃ列：Ａ列の値をＶＢＡのＦｏｒｍａｔ関数で変換　→ 0.5と2.5が異常 　　　　Function msFormat(v) 　　　　　　msFormat = Format(Val(v), "#,##0") 　　　　End Function
	次にＡｃｃｅｓｓでの例
		値：テーブルの値 Ｂ列：テーブルの値をＶＢＡのＦｏｒｍａｔ関数で直接変換　→ 0.5と2.5が異常 Ｃ列：テーブルの値を作成したＦｏｒｍａｔ関数で変換　→ 0.5と2.5が異常 　　　　Function msFormat(v) 　　　　　　msFormat = Format(Nz(v), "#,##0") 　　　　End Function
	ＭＳのページには解決方法も掲載されていますが、どこでＦｏｒｍａｔを使っているか調べるのが大変、ましてＱｕｅｒｙの中となると話はますますややこしくなります。私どものAccess97便利ツール AcSearch かHi.Ro.PonのおうちのAnalyzer2000を使うしかないようです。 ＭＳページの最下段「この情報へのご意見、ご要望がございましたらこちらへご記入ください。」には必ず一言文句をいって送信しましょう。
	FormatTest.lzhのダウンロード（FormatTest.xls と FormatTest.mdb） 　　　　FormatTest.mdbは2000です。
	＜テスト環境＞ 　　Windows XP Home Edition 　　Excel 2002 SR1 　　Access 2000 SR2
	＜関連ページ＞ 　　Fly Me To The Access Heaven
	（UPD:02/03/24）
Ole機能を使ってExcelに罫線を引く場合の注意点
	Ole機能を使ってExcelに罫線を引く場合、Cellsを使うと、このmdbを閉じるまでExcelのインスタンスが閉じません。 RangeオブジェクトをA1 形式で指定した場合はこのような現象は起きません。 　　With ws.Range(Cells(1, 1), Cells(11, 2)) 　　With ws.Range("A1:B11") Ctrl+Alt+Deleteで「プログラムの強制終了」を立ち上げて確かめてください。 CellsのあとにA1 形式を行うとAccessとExcelが不安定になります。Cellsのを実行したらいったんMDBを閉じてください。 訂正（01/04/02） Cellsにws.をつけるのを忘れておりました。オブジェクトがなくてもエラーにならないMSのおおらかさにはつねづね感謝しております。  インスタンスが残るのはこれが原因のようです。  このご指摘は　山本さんからいただきました。山本さんありがとうございました。
		ＳｏｕｒｃｅCode
	XlsQuit.mdbのダウンロード (XlsQuit.lzh  28Kb 01/04/02)
	（UPD:01/03/17）
Msgbox Val("９")は？（全角数字の扱い）
	全角の数字をVB（A)はどのように扱うのでしょう。
		VB 4 VBA  VB 6 9 0 0	VB 4に慣れ親しんだ私にはショックでした。
	（UPD:01/03/17）
RowSourceに2048バイトを超える文字列を指定するとエラー
	ComboBox、ListBoxで　RowSourceType/値集合タイプ" プロパティに [Value List/値リスト] を設定し、 リストを構成する値を "RowSource/値集合ソース" プロパティに指定する場合、RowSourceのバイト数が、2048バイトを超えるとエラーになります。「クエリー使えヨ！」ということなのでしょう。 VBになれた方はご用心ください。
	LsRowSource.mdbのダウンロード (LsRowSource.lzh  12Kb 01/02/17)
	（UPD:01/02/17）
Win NTでは動いて、Win 9XではエラーになるVariant型
	ファイルを配列に読み込む処理で
		Private Sub cmdVariant_Click() 　　Dim r() 　　ReDim r(FileLen(PrgPath & cFile)) 　　f = FreeFile 　　Open PrgPath & cFile For Binary As #f 　　Get #f, , r 　　Close #f 　　MsgBox "ファイルを配列に読み込みました", vbInformation, Me.Caption 　　Erase r End Sub
	とVariant配列へ読み込みを行なうと、Windows 9X系ではランタイムエラーになります。 　　Visual Basic でサポートされていないオートメーションが変数で使用されています。(Error 458) ところがWindows NT系では正常終了します。 Visual Basicでも同様の現象が起こります。 Win9Xで
		Dim r() As String
	とすれば問題なく処理します。 またUnicodeではなく１バイトずつ文字を取り出す場合は
		Dim r() As Byte
	を使います。   Variant.mdbのダウンロード (variant.lzh  19Kb 01/01/13) 余談ですがVBの次のバージョンではVariant型はなくなるそうです。For Each はどのように使うのでしょう、心配です。
	（UPD:01/01/13）

Accessの最適化メニューと、DbEngineのDatabaseCompactは処理が違う
Accessの「ツール」→「データベースユーティリティー」→「最適化／修復」の場合
    DataBase部分の最適化とAccessの編集過程で残ったゴミを最適化します。

DbEngineのDatabaseCompactの場合
    DataBase部分の最適化だけ行います。

最適化ダイアログを起動するには次のメソッドを使用します。
    DoCmd.Runcommand acCmdCompactDatabase
しかしDatabaseCompactのようにパラメータを与えてメニューの最適化をプログラムで実行することはできません。

（UPD:00/05/13,MS確認済み00/04/24）

プロパティシートに書いた日本語名の関数は実行時に認識されない場合がある
コーディング量を減らしたり、軽いフォームを作成する目的でプロパティシートのイベントプロシジャの代わりに関数を書く場合があります。日本語を含む関数では、プログラムが肥大化すると突然その関数を認識しなくなることがあります。この場合は、関数名を英数字に変更することで解決できます。可読性が良くなるため日本語を使いますが、プロパティシートに使う関数は英数字にしたほうが無難です。ちなみにクエリー内で使った関数ではこの現象を経験しておりません。

（UPD:00/05/13）

一箇所だけ修正してコンパイルしてもコンパイル済みにならない場合
少し修正後にコンパイルしてもコンパイル済みにならない場合があります。このような時はGeneralセクションで、改行をいれてまた戻す等の修正後に再度コンパイルすればコンパイル済になります。しかし安全のため、一度MDBを閉じてから再度開きコンパイルすることをお勧めします。

（UPD:00/05/13）

「定型入力」を設定した項目で発生するエラーメッセージ
「定型入力」を設定した項目で入力ミスをするとAccessは

このフィールドに入力した値が不正です。
たとえば数値型のフィールドに文字列を入力しました。

とお怒りになります。

たとえば日付項目に  定型入力　99\/99\/99;0;_
を設定して               00/02/30
を入力した場合に「定型入力規則違反だ！」というわけです。

でも日付が違うのですから「日付が違います！」と出したいのが人情。
しかし、日付項目の"BeforeUpdate/更新前処理"ではなく
Formの、"OnError/エラー時"で処理します。

Private Sub Form_Error(DataErr As Integer, Response As Integer)
    Dim ctrl As Control

    Select Case DataErr
    Case 2113 '定型入力エラー（アプリケーションエラー）
        Set ctrl = Screen.ActiveControl
        If Not IsDate(ctrl.Text) Then
            MsgBox "日付が違います。入力しなおすかEscキーを押し取り消してください。", vbCritical
            Response = acDataErrContinue
        End If
    Case 2169 '保存不可（入力ミスのままフォームを閉じられたときの対応）
        Response = acDataErrContinue
    End Select
    Set ctrl = Nothing
End Sub

更新前なのでTextプロパティで判定します。Textプロパティはフォーカスがあたってないとエラーになります。Screen.ActiveControlを使うのは日付項目が２つあった場合にどちらの項目か判定できないためです。あたりまえのことですがこのイベントを通るエラーはNameプロパティで判定してすべて処理する必要があります。

（UPD:00/02/26）

[AC97_2K]レポートのOpenイベントでSourceObjectを設定可能
ヘルプの「"SourceObject/ソースオブジェクト" プロパティ」には次のような記述があります。

メモ "SourceObject/ソースオブジェクト" プロパティは、レポートの Open イベント または Format イベントで設定したり変更することはできません。

しかしレポートのOpenイベントでSourceObjectを設定することは可能です。
もっともFormat イベントで設定すると次のメッセージを表示します。

実行時ｴﾗｰ'2191':
印刷が開始した後は、ソースオブジェクト プロパティを設定することはできません。
Openイベントが発生したときに、このプロパティを設定するようにしてください。

SourceObjectにはフォームの場合はフォームしか設定できませんが、レポートの場合はレポートとフォームの両方を設定できます。
この機能は画面をハードコピーイメージで印刷したい場合に新たなレポートを作成する必要がなく便利です。
この場合の注意点は
　　Me!埋め込み0.SourceObject = "Form.フォーム名"
のようにForm.、Report.をつけて記述しなければなりません。

（UPD:00/02/17）

Date関数でコンパイルエラー
たとえば「Date.mdb」のファイル名で新規にデータベースを作成しますとプロジェクト名は自動的に「Date」になります。VBAでDate関数を使うと次のエラーになります。
 コンパイルエラー「プロジェクトではなく､変数またはプロシージャを指定してください｡」
-----------------------------------------------------------------------------------------------------
Helpの内容
 現在の適用範囲に､この名前の変数またはプロシージャはありませんが､この名前のプロジェクトがあります｡
 エラーの原因と対処方法を次に示します｡
 プロジェクトの名前が､変数またはプロシージャとして使用されています｡
 変数名またはプロシージャ名を確認し､参照する名前が別のモジュールに対してプライベートでないことを確認します｡
 プロジェクト名は修飾子として使用できますが､プロジェクト名自体を独立して使用することはできません｡
-----------------------------------------------------------------------------------------------------
以上がAccessの定義ですが、
VBAの予約語でプロジェクト名に使用出来るものと出来ないものがあります。
Date関数はダメですがNow関数はOKです。調べてみると何の規則性もないのです。ともあれプロジェクト名に予約語を付けるなどというのは暴挙なのです。

ＳｏｕｒｃｅCode

  Project_Name.mdbのダウンロード (project_name.lzh  19Kb 2000/02/05)

（UPD:2000/01/29）

Access2000でOrderByプロパティーを設定する場合
Ac97では許されたのですが、Ac2000でOrderByプロパティーをVBAで設定する場合はフィールド名を [ ] で囲まないと [FieldName DESC] と解釈されてしまいます。もっとも汎用関数で [ ] で囲まなかった私がバカでしたが、MSには「余計なことをするナ」といいたいです。

ＳｏｕｒｃｅCode

  LsSort.mdbのダウンロード (lssort.lzh  56Kb 2000/01/29)

（UPD:2000/01/29）

Access97でIME2000を使うと問題が発生する場合

Access97でIME2000を使うと、定型入力：@9@9を設定したテキストボックスにテンキーからの数字が入力できません。キーボード上の数字入力は可能です。IME97ではいずれの場合も数字入力が可能です。
定型入力：99ならばIME2000、IME97とも数字入力が可能です。ただしあたりまえですが表示はすべて半角になりま　す。
　Ａｃｃｅｓｓ97版サンプル　(ime_mode.lzh/14k)

※ Access97からAccess2000に変換すると、定型入力：@9@9は99に変換されてしまいます。

※ Access2000では、@は定型入力文字からはずされ、定型入力プロパティに入力もできません。

（UPD:2000/01/22）

Access97/2000、VBの2001年問題

Access97/2000のVBAまたはVBで、日付を含むSQLを書いた場合に不具合が生じます。それもY2K問題も落ち着いたころに発生するという念のいれようで、ＭＳに感謝感激雨あられ！

MSの納得できないFAQ: [VB] 日付リテラルにより日付を設定するときの注意 (最終更新日: 2000/01/11)

対象言語：Access97/2000のVBAとVB(Ver4でのみ確認)

発生条件：\WINDOWS\SYSTEM\OLEAUT32.DLLのバージョンが 2.40.xxxx でかつ、ｺﾝﾄﾛｰﾙﾊﾟﾈﾙ「地域−日付」の短い日付形式が yy/mm/dd の場合

対象日付：2001/01/02 〜 2012/12/31

現象：日付を米英語の日付書式(dd/mm/yy)として扱う。これはAccessのヘルプで「日付」の項目の「SQL ステートメントでの国際日付書式の使用」に記述されています。
    例  01/01/12(2001/01/10) を 2010/01/01 として扱います。

対策：
    �@ｺﾝﾄﾛｰﾙﾊﾟﾈﾙ「地域−日付」の短い日付形式を yyyy/mm/dd に設定します。
        もっとも簡単ですが、設定を変えられたら終わりです。

    �Aformat関数を使い yyyy/mm/dd に変換します。
        手間がかかりますが確実です。
        手順は
            1)次の４文字を検索し、４文字のあとに Format( を追加します。
                    #" &
            2)日付のあとに ,  "yyyy/mm/dd") を追加します。
            例
                strSql = "select * from テーブル1 where dt" & kigou & "#" & Combo1.Text & "#;"
                    ↓
                strSql = "select * from テーブル1 where dt" & kigou & "#" & Format(Combo1.Text, "yyyy/mm/dd") & "#;"

●Accessのクエリーで日付を使った場合は正常に処理されます。

　Ａｃｃｅｓｓ97版サンプル
  ＶＢ４版サンプル（Ａｃｃｅｓｓ97版サンプルもダウンロードしてください）
        サンプルではＡＰＩを使って次のことを行なっています。
            ・OLEAUT32.DLLのバージョンの表示
            ・ｺﾝﾄﾛｰﾙﾊﾟﾈﾙ「地域−日付」の短い日付形式の表示


関連サイト：Ac Propaganda

（UPD:1999/11/06,2000/02/05）

Access97/2000の共存(Windows95の場合)

Windows95の環境でAccess97/2000を共存した場合、Ａｃｃｅｓｓ2000終了時に「不正な処理を・・・・」で異常終了する場合があります。
単純にバージョンアップした場合もこのエラーが発生する場合があります。

プログラム（VBA)でＡｃｃｅｓｓ2000を終了させた場合は　
        MSACCESS のﾍﾟｰｼﾞ違反です。
        ﾓｼﾞｭｰﾙ : KERNEL32.DLL、ｱﾄﾞﾚｽ : 014f:bff9a78c(以下略)

閉じるボタンでＡｃｃｅｓｓ2000を終了させた場合は　
        MSACCESS のﾍﾟｰｼﾞ違反です。
        ﾓｼﾞｭｰﾙ : FPX32.FLT、ｱﾄﾞﾚｽ : 014f:0c96fbfb(以下略)

のような詳細になります。MSによりますと次のファイルを削除することで、このエラーは発生しなくなるとのことです。実際弊社の環境でも発生しなくなりました。

\Program Files\Common Files\Microsoft Shared\Grphflt\Fpx32.flt

このファイルは富士フィルムの画像フィルタファイルだそうで、MSでは現在異常終了する原因を調査中です。

補足事項
Officce97の環境をきれいに削除したい場合は、CD-ROMのつぎのプログラムを実行させます。
\Pfiles\Msoffice\Office\Offcln9.exe

（UPD:1999/10/09,ｍｓ確認済み1999/10/08）

Access97/2000の共存

Access95/97の共存で悩んだ方へ朗報（？）です。断定はできませんが、Access97/2000の共存は大丈夫のようです。Access97使用後、Access2000を起ちあげるとAccess2000が環境を整えてくれるようです。当然のことですがAccess2000は別フォルダにインストールしなければなりませんし、ｍｄｂ当の拡張子にはAccess2000が関連付けられます。編集、MDEの作成は両環境で問題なくできておりますが、ランタイム配布はテストを行なっておりませんので解りません。
あくまで個人的な意見ですがランタイム配布はやめたほうがいいようです。少なくともＩＥ４以上の環境で作成されたランタイム配布をＩＥ４未満の環境にインストールした場合、確実に環境を破壊(comctl32.dllが書き換わります)し、ＶＢ４で作成されたプログラムが動作しなくなる可能性があります。
ご注意：マイクロソフトはバージョンアップ版のAccess2000とAccess97の共存はライセンス違反だとしております。

（UPD:1999/08/28）

Accessの常識 「Setを使ったら、Nothing」

キーワード Nothing は、オブジェクト変数とその変数が参照しているオブジェクトとの関連付けを解除するために使います。
Set ステートメントを使って、次のようにキーワード Nothing をオブジェクト変数に代入します。

Set MyObject = Nothing

複数のオブジェクト変数が同じオブジェクトを参照することがあります。キーワード Nothing をオブジェクト変数に代入すると、その変数は実際のオブジェクトを参照しなくなります。複数のオブジェクト変数が同じオブジェクトを参照すると、
各変数が参照するオブジェクトに関連付けられたメモリとシステム リソースは、Set ステートメントを使ってすべての変数を明示的にキーワード Nothing に設定するか、またはキーワード Nothing に設定した最後のオブジェクト変数が、
暗黙のうちに適用範囲 (スコープ) 外になった後でなければ解放されません。

以上「Access97のヘルプより」

つまり、Setを使って設定したオブジェクト変数は　Nothing　を設定しないとメモリとシステム リソースを食い荒らすぞということです。サンプルプログラムではあまり　Nothing　を見かけませんが、実務プログラムではこの原則を忘れないでください。VB、VBAのヘルプにも同様の記述があります。

（UPD:1999/07/21）

最適化を行なってもAccessのサイズが大きいと感じたら                                

Access97はかなり行儀の悪いアプリケーションです。実行時にも、編集過程でもどんどんゴミを製造します。今はやりの言葉で言えば「環境にやさしくない」アプリで、このゴミを一挙に片づけてくれるのが「最適化」です。ゴミが溜まりすぎてから最適化を行なうと、必要なものまで消されてしまうことがありますので、最適化はこまめに行なうよう心がけましょう。私の経験では、フォームに書いたVBAが消えてしまったことがあります。この状態で「修復」を行なっても意味がありませんし、MSでも「あきらめてくれ」とにべもありません。つまり壊れたMDBを復旧する手だては何もないのです。これでAccessプログラミングにおいて、最適化とバックアップがいかに大事かを理解頂けたかと思います。

最適化も万全ではなく、ウィザードが出したゴミの整理はやってくれません。
１．無意味な空白行
「ツール」→「オプション」→「モジュール」でモジュール全体を連続表示にしてから（初期値ではチェックがはずれています）、フォーム等のVBAを開いてみて下さい。End Subと次のSUBモジュールの間に余分な空白行が挿入されていますので削除します。
２．ウィザードで作成したモジュールのエラー処理ルーチン
モジュール内に　On Error Goto xxxxxx がある場合、その必要性を吟味しましょう。ウィザードで作成したエラー処理ルーチンはほとんどの場合必要ありませんので削除します。
３．ウィザードで作成したフォーム・レポートのタグのゴミ
フォーム・レポートのラベルコントロールのタグプロパティーをチェックして下さい。DetachedLabelと記述されている場合はそのラベルコントロールが他のコントロールに関連付けられていることをあらわします。つまり、他のコントロールを使用不可にすれば、自動的にそのラベルコントロールも使用不可に変わります。ほとんどの場合関連付けは必要ありませんのでDetachedLabelを削除します。55個のラベルコントロールからDetachedLabelを削除して２０４８byteサイズが小さくなりました。

フォームまたはレポートのクラス モジュールを標準モジュールに移し、コード保持（HasModule） プロパティをいいえに設定して、軽いフォームまたはレポートにします。
たとえば Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer) のような引数付きのイベントモジュールで引数を使う場合は移動できません。
メニュー用のフォーム、サブフォームを持つフォームなど入力項目のないフォームは比較的簡単に移行できます。
詳しくはコード保持（HasModule） プロパティのヘルプを参照して下さい。

よく使う文字列の定数化
    MsgBox "電話番号の入力が違います。", vbCritical,   "住所入力"
    の"住所入力"ようによく使う文字列を定数化します。

    Public Const cProgramName = "住所入力"
    ・・・・・・
    MsgBox "電話番号の入力が違います。", vbCritical, cProgramName

共通する処理の関数化
イベントドリブン型のモジュール内には同様の処理が意外とたくさんあります。たとえばラベルをクリックすればソートを行なうといったプログラムの場合、フォームとソートする項目を渡して、共通関数内でソート処理を行ないます。

余分なコメントは削除する
MDBの場合、コメントもプログラムサイズの一部です。余分なコメントは必ず削除します。特にヘルプの使用例からコピーしたソースは余計なコメントが多いので見直しが必要です。

モジュールを含むMDBはできればMDEにする
MDEにすると物にもよりますが約２０％のサイズダウンになります。MDEにするとモジュールはすべてコンパイルされ、編集可能なソース コードはすべて削除されます。いくつかの制限がありますが、試してみる価値はあります。

とりあえず気づいたものを列挙しましたが、このような方法で２．７メガバイトのMDBを１メガバイトにしたことがあります。
ウイザードとヘルプの使用例だけで作成したようなプログラムを数十万円で売りつける業者も現存しますので、発注する場合は注意が必要です。このような業者が上記のような注意を払っているわけがありませんから、システムが途中でおかしくなっても不思議ではありません。

このページの内容に関連するお勧めサイト：Fly Me To The Access Heaven

（UPD:1999/05/15）

Access95からAccess97に変換時に「ｵｰﾄﾒｰｼｮﾝ ｴﾗｰです｡」のメッセージが出る  Access95のDataBaseをAccess97に変換すると「ｵｰﾄﾒｰｼｮﾝ ｴﾗｰです｡」のメッセージが出て変換できない場合は、旧DBに編集過程のごみが残っている可能性があります。

回避方法：

１．問題のDataBase（仮にtest.mdbとします）は必ずバックアップをとります。
Accessで変換、最適化、MDE作成等を行う場合は事前にバックアップをとるのが原則です。

２．Access95の環境でDataBaseを新規作成します（db1.mdb）。

３．「ファイル」→「外部データの取り込み」→「インポート」でtest.mdbのすべてを取り込みます。

４．モジュールを開き「デバッグ」→「すべてのモジュールのコンパイル」を行います。コンパイルエラーが出た場合は修正します。もともとのtest.mdbではコンパイルエラーがなくここでコンパイルエラーが出る場合もあります。

５．新しく作成したdb1.mdbを最適化し、test.mdbに改名します。

６．test.mdbをバックアップしてから、Access97の環境でtest.mdbを変換します。

（UPD:1999/05/01）

サブレポートのOpenイベントでOrderByプロパティーを設定するとエラーになる  

サブレポートのOpenイベントでOrderByプロパティーを設定すると次のエラーが発生します。
実行時エラー：２１０１
プロパティーの設定値として指定した値が不正です。

サブフォームの場合は正常に動作します。

回避方法：
１．CreateGroupLevel 関数を使って、並べ替えを設定する。
CreateGroupLevel 関数はデザインビューでしか使用できないため、MDEの場合は次の方法を取らざるを得ません。

２．サブレポートをやめ、クエリーを1本化してサブレポートを含まないレポートにします。

（UPD:1999/05/01,ｍｓ確認1998/07/09）

クロス集計クエリーで、「行見出し」の値が４５文字を超えると値が表示されない場合がある                                

回避方法：「行見出し」の値を45文字以内に制限する以外方法がありません。

　サンプルＭＤＢのダウンロード (qa_clos.lzh  8Kb 1999/05/01)

（UPD:1999/05/01,ｍｓ確認済み1998/06/09）