MS AccessでMySQLを利用する際の注意点 MySQL X Facebook LINE 2013.08.282023.03.11 MySQLの制限事項-Access2000から操作する際に発生する問題点 アプリケーションの移植作業もなかなか進みません。ひとつ何かをやると複数の問題点が絡み合って返ってきます。 数も多いので覚えきれません。さっそくここで覚え書きを残しておこうと思います。 MyODBCドライバのオプションフラグ“Return matching rows”を有効にする。 Accessから利用するすべてのMySQLテーブルに主キーを設定する。 Accessから利用するすべてのMySQLテーブルにTIMESTAMP(14)またはTIMESTAMPカラムを定義する。 ※TIMESTAMP型はINSERT、UPDATE操作時に自動的に現在の時刻が表示されるカラムです。データの更新日として使っているカラムがなければ”[テーブル名]_last_update”等のカラムを新しく作成する必要があります。 浮動小数点型はDoubleだけ使用する(単精度浮動小数点型は使用しない事) BIGINT型を使用する場合、>MyODBCドライバのオプションフラグ“Change BIGINT columns to INT”を有効にする。 ODBCの設定を変更した際は、テーブルリンクをいったん削除し、リンクを張り直さないと設定が反映されない事がある ODBCの設定を変更した際は、Accessをいったん閉じて開き直す必要がある場合がある Accessのフォームから操作する場合、TIMESTAMP型のカラムに対して規定値でNow()を設定する必要がある場合がある AccessがMySQLのDATE型を正しく処理できない場合がある。その場合DATETIME型に変更する。 AccessからMySQLへテーブルを移行する際、日付型のカラムが原因となることがある。回避する為には、MySQL側の日付型カラムはDATETIME型に、Access側の日付型カラムは書式を日付(標準)にする必要がある。 AccessからMySQLへテーブルを移行する時に、ファイルメニューのエクスポートを使用すると、問題発生時にどのカラムに問題があるのか把握できない場合がある。問題を明らかにするためには、MySQLで事前にテーブル構造を準備しておき、Accessのテーブルから追加クエリを使用してデータを移してやればよい。ひとカラムずつデータが移行できているのか確認することで問題が明らかにすることが出来る。 MySQL側にBIGINT型のカラムがあるテーブルをリンクテーブルにした場合、すべてのカラムに#Deleted#と表示されることがある。その際はBIGINT型をINT型にすることで表示されるようになる。MySQLのINT型とAccessのLong型(長整数型)がちょうど同じ範囲の型なので整数型は迷わずINT型を使おう。範囲が広いからと言ってBIGINTを使う必要性はあまりない。なんとかしようとするとドツボにはまります。 MySQLの日付型のデータの範囲は1000-01-01から9999-12-31まで。Accessは1000年以前が入力できる(例.153年1月1日)。データ移行の際にAccess側に1000年未満のデータがある場合、オーバーフローが発生する。
アプリケーションの移植作業もなかなか進みません。ひとつ何かをやると複数の問題点が絡み合って返ってきます。 数も多いので覚えきれません。さっそくここで覚え書きを残しておこうと思います。 MyODBCドライバのオプションフラグ“Return matching rows”を有効にする。 Accessから利用するすべてのMySQLテーブルに主キーを設定する。 Accessから利用するすべてのMySQLテーブルにTIMESTAMP(14)またはTIMESTAMPカラムを定義する。 ※TIMESTAMP型はINSERT、UPDATE操作時に自動的に現在の時刻が表示されるカラムです。データの更新日として使っているカラムがなければ”[テーブル名]_last_update”等のカラムを新しく作成する必要があります。 浮動小数点型はDoubleだけ使用する(単精度浮動小数点型は使用しない事) BIGINT型を使用する場合、>MyODBCドライバのオプションフラグ“Change BIGINT columns to INT”を有効にする。 ODBCの設定を変更した際は、テーブルリンクをいったん削除し、リンクを張り直さないと設定が反映されない事がある ODBCの設定を変更した際は、Accessをいったん閉じて開き直す必要がある場合がある Accessのフォームから操作する場合、TIMESTAMP型のカラムに対して規定値でNow()を設定する必要がある場合がある AccessがMySQLのDATE型を正しく処理できない場合がある。その場合DATETIME型に変更する。 AccessからMySQLへテーブルを移行する際、日付型のカラムが原因となることがある。回避する為には、MySQL側の日付型カラムはDATETIME型に、Access側の日付型カラムは書式を日付(標準)にする必要がある。 AccessからMySQLへテーブルを移行する時に、ファイルメニューのエクスポートを使用すると、問題発生時にどのカラムに問題があるのか把握できない場合がある。問題を明らかにするためには、MySQLで事前にテーブル構造を準備しておき、Accessのテーブルから追加クエリを使用してデータを移してやればよい。ひとカラムずつデータが移行できているのか確認することで問題が明らかにすることが出来る。 MySQL側にBIGINT型のカラムがあるテーブルをリンクテーブルにした場合、すべてのカラムに#Deleted#と表示されることがある。その際はBIGINT型をINT型にすることで表示されるようになる。MySQLのINT型とAccessのLong型(長整数型)がちょうど同じ範囲の型なので整数型は迷わずINT型を使おう。範囲が広いからと言ってBIGINTを使う必要性はあまりない。なんとかしようとするとドツボにはまります。 MySQLの日付型のデータの範囲は1000-01-01から9999-12-31まで。Accessは1000年以前が入力できる(例.153年1月1日)。データ移行の際にAccess側に1000年未満のデータがある場合、オーバーフローが発生する。