MDBファイルのテーブルをＭｙＳＱＬにエクスポートしてみると、テーブルの構成に色々と問題が出てくる。
特にNULLを許可するかどうかが一番の問題。
作ったプログラムが許容できなかった場合を考慮して、フィールドが Not NULLだったり、初期値を設定してあれば、それと取り込んでALTER TABLEすれば大体問題は解消。
AutoNumberもNIQUE KEY扱いしてAUTO_INCRIMENT属性を付ければ何とかなる。
[MySQL]ODBC接続でフィールドの番号を振り直してみる
しかし、それでは気が付かないモノもあった。
Bit型のフィールドだ。
MS-ACCESSではYes/NoのフィールドがBit型(長さ1)のフィールドに変換されるがNULLはOKとなっている。でも大丈夫かと思ったら、そうでは無かった。
MS-ACCESSの連携フィールドではチェックマークになる。
このフィールドがある場合に「＊」でレコードを追加する際に先のチェックを入れないと、何故かBit型のフィールドに NULL が入ってしまう。
それでも、MS-ACCESS上で支障がなければいいが、そうなっていない。
ビューの上では追加した行にDELETEマークが並ぶ。ビューを最新表示すれば消えるが、その行を編集や削除をすると、
と、いつもの頓珍漢なメッセージが出てしまい、何が原因か全く判らない状況に陥ってしまう。しかし、サーバやPCを再起動しても、リンクテーブルのビューでも編集や削除をすると、同じメッセージが出るので、
MSーACCESSが何かトチったことが判る。
PHPMｙSQLでBit型がNULLになっているとこを０に変えると問題は解消される。
つまり、INSERTで設定した（つもりの）値と違う内容がレコードに入っていたので、誰かが書き換えたに決まっている！とMS-ACCESSは判断をしたらしい。
実際にはINSERT時はBitフィールド型が未設定の様だ。それをやっちまっているのはMS-ACCESSなのかMySQLのODBCドライバなのかは判らないケドね。
SELECT * FROM テーブル名 WHERE Bitフィールド名 IS NULL;なレコードをポチポチ直すものいいけど、
UPDATE テーブル名 SET Bitフィールド名 = 0 WHERE Bitフィールド名 IS NULL;で焼き尽くしても、どうせ、すぐに増えるから・・・直ぐに！
ALTER TABLE テーブル名 CHANGE Bitフィールド名 Bitフィールド名 BIT( 1 ) NOT NULL DEFAULT b'0';と、BitフィールドでNULLを禁止し、初期値も0にした方がいいだろう。
※bit(2)とかbit(3)に変換されるフィールドもあるのかもしれない。（ケド
一応、
SELECT table_schema, table_name, column_name FROM information_schema.columns WHERE data_type = 'bit';で見ると、bitフィールドが意外にいっぱいあったりする。
エクスポートする際は、bitフィールド型も要注意。（ダナ
SET sql_mode='PIPES_AS_CONCAT'; select 'UPDATE `' || table_schema || '`.`' || table_name || '` SET `' || column_name || '` = 0 WHERE `' || column_name || '` IS NULL;',
'ALTER TABLE `' || table_schema || '`.`' || table_name || '` CHANGE `' || column_name || '` `' || column_name || '` BIT(' || NUMERIC_PRECISION || ') NOT NULL DEFAULT b''0'';'
FROM information_schema.columns WHERE data_type = 'bit';これを実行すると全データベースのBitフィールドをサッパリにするSQLを吐き出す。ALTER TABLEは1行づつ整合性チェックが入るみたいなのでレコード数が多いと結構時間がかかる。（ッヨ！
※SETはconcatを使うとミスが見つけにくいので、 || を使ったから。
※UPDATEしてるのは、NULLデータがあるとALTER TABLEでNOT NULLが整合性エラーで弾かれるから。
さて、絶対安全？MS-ACCESSからMySQLへのエクスポートのVBAに手を入れなければ・・・
