藤原です。

> 村上です。
> 
> > 藤原です。
> 
> >   実際に、テーブルを作ってテストしてみました。
> > 
> >   ALTERしても、以前から入っているデータはそのまま長くても入ったままで
> >   した。
> >   新たに入れたり変更しようとした場合にだけ、新しく解釈された長さで切ら
> >   れますね。
> 
> そうなんです。
> 見た瞬間に「んん？」と思ってしまいます。
> 
> 逆に 4.1 で char(255) で作ったテーブルを、4.0, 3.23 でアクセスさせると
> これまた「え！？」な状態です。

  なるほど、バージョンアップの時には3で割られ、バージョンダウンのとき
  には3が掛けられるという訳ですね。

  255を越えても TEXT にはならない。（そんなことをするのは大変か）

> サーバーが自動で変換することは、私は考えていません。
> DB 管理者が、手動で変換する方がいいと考えています。
> 単純に shell でも Ruby でも、スクリプトを書けばいいと。
> 
> そのスクリプトの例が ML にでも MyNA の web などにでもあれば、
> スクリプトが無いとあるとじゃ大違い、と考えています
> スクリプトは簡単なものでいいと考えています。存在することが大事。
> 
> スクリプトでの判定方法ですが、
> 
> SHOW TABLE STATUS; 
> に、ver という項目を付けて、そこに frm のバージョン番号を出すように
> 開発者側に投げておきました。
> 返ってくる数値や項目名はどうなるかは未定ですが、
> SHOW TABLE STATUS; 
> .... |ver|
> .....|  7|
> の結果を見ればいいということです。

  カラムに入れる中身で妥当な値は違うので、最後は手作業で充分でしょうね。

> Warning を出す件ですが、
> Warning は、私の方からは、全てのクエリ実行時に出して欲しいという
> 話を投げましたが、
> 開発側は、全てには Warning を出したくないらしくて
> Warning は限定されたクエリでしか出ないようになる雰囲気です。
> # そりゃ、1バイトしか使っていない人にはうっとおしいのはわかるが、
> # 仕様が大きく違うので出した方がいいぞ

  私は、Warningは必要性は低いと思います。

  それより、こういう問題があるということを、マルチバイト文字列を使って
  いる人がバージョンアップ対応しようとする場合に注意しないといけないと
  いうのが知れ渡っていないことが大変問題かと。

------------------------------------------------------------------
株式会社 タイムインターメディア       藤原 博文 fuji@xxxxxxxxxx
本社 160-0002 東京都新宿区坂町26-27 ＩＰＢビル    TEL 03-5362-9009
URL  http://www.timedia.co.jp/                    FAX 03-5362-9008
地図 http://www.timedia.co.jp/company/map/     新宿線曙橋駅徒歩5分
------------------------------------------------------------------
♪  Puzzle Japan  http://www.puzzle.jp/  毎日新作パズルで遊ぼう ♪
------------------------------------------------------------------