>はODBC内部ではCHAR型です。
あぁ、そうなんですね。

>現在の仕様は
>TINY BLOB
>BLOB
>MEDEUM BLOB
>LONG BLOB
>に格納されているときはバイナリとみなし
>コード変換せずに取り出します。
なるほど。そうすると、それに気を付けて、
ODBCでバイナリを扱う場合の制限事項みたいなものと、予め
理解した上で使えば問題なしということでしょうか。

>私はバイナリデータは別ファイルにして保存し、そこへパスなどののポインタをテキストで
>DBに挿入する主義ですから、必要ないのですけど、できないと困る人もいるでしょうね。
多分、私もバイナリデータを扱う場合には、同じやり方をとると思います。

>ODBCでは各フィールドの型は前もってわかっているようなので、クエリーを解析して
これは有り難いですね。
ではMySQLとODBCの間で、型の対応関係が一意ということみたいですから、

>フィールド名と型の照合をやってバイナリ(BLOB)かどうかを判断するのが、いいよう
ができれば、コードを変換するか、しないか、ということになりますね。

>な気がします。INSERTとUPDATEの構文解析ができれば可能かなと思っています。
>本当かな…;
えっと念のため、SELECTの時も、同じような・・・。
取り出すときにも、バイナリでなければ、コード変換は必要ですよね。
型を評価しているところ、MySQLとODBCの型の対応をとっている部分が
分かればＯＫのような気がいたします。

＃プログラミングのことはよく分かりませんが、現在SJIS<->EUC変換を
＃行なっているところ、\エスケープを行なっている箇所に関連した場所
＃ではあるのですよね？

バイナリであれば、SJIS<->EUC変換は不要で\エスケープのみ。
バイナリ以外は、SJIS<->EUC変換と\エスケープの両方を行なう。

あ、構文解析というのは、型の評価をしている方法、場所がINSERT、UPDATE
のところを調べれば、分かるということですか？
====================================
 ^^ ^^  mailto:wm@xxxxxxxxxx ^^ ^^
   Masato  Toyoshima    豊島　正登