(現在 過去ログ35 を表示中)

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

[ 最新記事及び返信フォームをトピックトップへ ]

■5485 / inTopicNo.1)  外部での書き出し時の上書きについて
  
□投稿者/ 尾形 -(2009/12/25(Fri) 10:35:28)
    よろしくお願いします
    MySQLです

    過去にも話題となっているようですが
    外部dbでの書き出しが上書きされてしまう件です

    会話処理で外部db追加書き出し
    テーブル名を 小文字 にしたらダメ(上書きされる)
    テーブル名を 大文字 にしたらokでした
    (過去のhidetakeさんのご指摘通り)


    テーブル trn_uriage_m_del に書き出しした場合のクエリーログ
    > 18 Query SHOW TABLE STATUS LIKE 'TRN_URIAGE_M_DEL'
    > 18 Query DROP TABLE `trn_uriage_m_del`
    なんでココだけ大文字が出てくるのか orz
    コマンドと間違えているとしか思えないのだけど (^^;;


    # 書き出し用のテーブル名は数値のみにしないとダメですね

引用返信 [メール受信/OFF] 削除キー/
■5486 / inTopicNo.2)  Re[1]: 外部での書き出し時の上書きについて
□投稿者/ hidetake -(2009/12/26(Sat) 12:03:03)
    2009/12/26(Sat) 12:04:34 編集(投稿者)

    > テーブル trn_uriage_m_del に書き出しした場合のクエリーログ
    >>18 Query SHOW TABLE STATUS LIKE 'TRN_URIAGE_M_DEL'
    >>18 Query DROP TABLE `trn_uriage_m_del`
    > なんでココだけ大文字が出てくるのか orz
    > コマンドと間違えているとしか思えないのだけど (^^;;

    ここだけでなく桐の外部DBにはどうしようも無いところが
    一杯あります。それは、kthree も数年前に知らせてあるし、
    改善すべき問題であると認識しているという回答は頂いて
    おります。でも、それっきりです。

    桐は、外部DBに対しては #u と "" の制御もまともに行え
    ていないし、ユーザがいろんなところでごまかして使うし
    かないと思います。


    > # 書き出し用のテーブル名は数値のみにしないとダメですね

    MySQL のデフォルトのファイル名が SQL標準と同じ大文字を
    前提としているならば、大文字で統一し試してみたり、大文字
    小文字のない文字(数字や漢字)を使うのも一つの手でしょう。
    あるいは、トリガなどを使ってごまかすのも1つの手だと思い
    ます。

    ※参考※
    http://www.fuku3.com/habata/kbbs/kakov9/26449.htm


引用返信 [メール受信/OFF] 削除キー/
■5487 / inTopicNo.3)  Re[2]: 外部での書き出し時の上書きについて
□投稿者/ 尾形 -(2009/12/26(Sat) 13:39:48)
    なんとなくですけど

    > 18 Query SHOW TABLE STATUS LIKE 'TRN_URIAGE_M_DEL'
    ココでテーブル情報(テーブルがあるか?)を桐が把握している
    のではないのかなぁと思ったのです
    このクエリーだけファイル名が大文字で出ているように見えました
    このクエリーを発行する時に、SQLコマンドと間違えて(バグ?)
    大文字でだしているのではないかなぁと・・・
    他の部分は全て小文字で出てたようなので

    それでDB側から、そんなテーブルありませんよって返答が来て
    > 18 Query DROP TABLE `trn_uriage_m_del`
    ドロップ命令だして、クリエイト命令かけているのでは
    と妄想しました


    そんな単純じゃないかな (^^;

引用返信 [メール受信/OFF] 削除キー/
■5488 / inTopicNo.4)  Re[3]: 外部での書き出し時の上書きについて
□投稿者/ hidetake -(2009/12/26(Sat) 15:33:01)
    >>18 Query SHOW TABLE STATUS LIKE 'TRN_URIAGE_M_DEL'
    > ココでテーブル情報(テーブルがあるか?)を桐が把握している
    > のではないのかなぁと思ったのです
    > このクエリーだけファイル名が大文字で出ているように見えました
    > このクエリーを発行する時に、SQLコマンドと間違えて(バグ?)
    > 大文字でだしているのではないかなぁと・・・
    > 他の部分は全て小文字で出てたようなので
    >
    > それでDB側から、そんなテーブルありませんよって返答が来て
    >>18 Query DROP TABLE `trn_uriage_m_del`
    > ドロップ命令だして、クリエイト命令かけているのでは
    > と妄想しました

    PostgreSQL だと、最新の ODBCドライバの状態で、テーブル名が
    全て大文字だと「追加」で書き出しが可能です。

    テーブル名が全て小文字だと、書き出す寸前で大文字のテーブル
    名を表示しそんなテーブルはありませんとエラーになります。

    テーブル名に大文字小文字混在の場合だと(ex. 'Test Data')
    勝手に 'Test Data' のテーブル名で、「追加」なのに「上書き」
    で、毎度毎度、新規にテーブルを作り直しデータを追加(INSERT)
    します。

    桐は、接続して最初にテーブルの一覧を取得し、その中に自分が
    扱おうとするテーブル名らしきものがあると、LIKE をつけ、その
    存在を確認するようです。
    'Test Data' と言うテーブルがあり、これに追加書き出ししよう
    とすると、まず 'TEST DATA' の存在を確認し、次に 'test data'
    の存在を確認します。
    両方とも実際には無いので、'Test Data' と言う正しいファイル
    名で DROP します。そして、テーブルを作り直し、データを追加
    していきます。

    'test data' の場合は、'TEST DATA' をチェックし、次に
    'test data' をチェックしますが、ありますので、項目などの
    情報を取得し、最終的に書き出す段になり、'TEST DATA' と言う
    大文字のテーブル名で insert をかけますので、その時にそんな
    テーブルは無いとエラーになります。

    'TEST DATA' の場合は、詳しくはログは取って見ていませんが、
    'TEST DATA' をチェックした段階で実在するので、次に項目情報
    などを取得し、書き出す際も、テーブル名を桐が大文字に勝手に
    変えたとしても違いは無いので、'TEST DATA' に正しく追加され
    ます。

    一応、以上が PostgreSQL での最新のドライバでの動作状況です。
    PostgreSQL でもドライバにより異なる動作になる場合があった
    ので MySQL について、どうなるのかまではわかりません。

    大文字・小文字問題は「外部DB書き出し」だけでなく、単純な
    結合でも桐は抱えています。それが表に出るか出てこないかは
    テーブル名のエイリアスを使うか使わないかに、まず依存すると
    思いますが、それだけだったかは忘れました。

    # 桐の外部DBでは、前に Microsoft SQL Server 相手に、#u なり
    # "" で置換を行うと、置換が悪しくなることがありました。
    # PostgreSQL では変な事にはならなかったけど、そう言うことも
    # 一つずつ試しながら使いこなしていく必要があると思います。 orz
    # これって桐9 になってからの問題だったけど、どうなったのかな?
    # 手元に SQL Server が無くなったので試していないや・・・


引用返信 [メール受信/OFF] 削除キー/
■5489 / inTopicNo.5)  Re[4]: 外部での書き出し時の上書きについて
□投稿者/ hidetake -(2009/12/26(Sat) 17:33:07)
http://dev.mysql.com/doc/refman/5.1/ja/identifier-case-sensitivity.html
    MySQL の場合、この辺で解決できないのかなぁ〜?

    8.2.2. 識別子の大文字/小文字区別
    http://dev.mysql.com/doc/refman/5.1/ja/identifier-case-sensitivity.html

    lower_case_table_names=1

    # しかし、MySQL はテーブルをファイルシステムの1つの
    # ファイル(定義やインデクスとかも別ファイルとして)と
    # して持っているんだ。

引用返信 [メール受信/OFF] 削除キー/
■5491 / inTopicNo.6)  Re[4]: 外部での書き出し時の上書きについて
□投稿者/ hidetake -(2009/12/26(Sat) 22:21:00)
    大文字・小文字問題参考メモ


    DBMSでテーブル名とフィールド名をクォートした際の挙動を知る
    http://old-journal.sooey.com/2008/12/12/873/

    > PEAR::MDB2のリードメンテナであるLorenzo Alberton氏による、
    > DBMS identifiers and case sensitivityが興味深い。DBMSで
    > 「テーブル名やフィールド名をダブルクォートで囲んだ」場合に
    > 大文字小文字がどのように扱われるのかということをちゃんと
    > 意識しないとダメですよ、という内容。
    >
    > SQL:2008とSQL-99では「クォートしない限りケースセンシティブに
    > はならない」(大文字小文字を区別しない)としており、DB2、
    > Oracle、Interbase(Firebird)はこれに合致している。PostgreSQL
    > の挙動も同様だが、前者が「非クォート時に大文字」となるのに対して、
    > こちらは「非クォート時に小文字」になる点が異なる。
    >
    > MySQLはテーブルがファイルシステム上にファイルとして格納される
    > ため、OSよって挙動が異なっている。Windowsの場合は「非クォート
    > 時もクォート時も常に小文字」となり、それ以外(Linuxなど)では
    > 「非クォート時はそのまま」となる。これは2つのシステムで、
    > lower_case_table_namesオプションのデフォルト値が異なることに
    > よる。なお、フィールド名については「クォート時も非クォートも
    > 常に表記通り」となる。
    >
    > SQLiteとSQLServerでは、テーブルおよびフィールドの作成時に限り
    > 「クォート時も非クォートも常に表記通り」となり、以降はクォート
    > 時も非クォート時も大文字小文字の区別はなくなる。
    >
    > そもそもケースセンシティブな名前を使わないのが一番いいんですが、
    > レガシーなデータベースと格闘するときはそうも言ってられないわけで…。




    クロスプラットフォームなテーブル名 - MySQL編
    http://journal.mycom.co.jp/news/2009/05/19/024/index.html

    > Craig Buckler氏は記事の最後で個人的なことだが、データベース名、
    > テーブル名、インデックス名、キー名などMySQLで利用する名前には
    > 小文字を使うようにしているという説明がある。使う名前を小文字で
    > 統一するのが簡単で効果的な方法というわけだ。



引用返信 [メール受信/OFF] 削除キー/
■5492 / inTopicNo.7)  Re[5]: 外部での書き出し時の上書きについて
□投稿者/ 尾形 -(2009/12/27(Sun) 09:55:24)
    > lower_case_table_names=1
    コレで解決しました ^^

    やっぱり単純な事ではないのですね
    思いつきで気楽に書いてすいませんでした
    お手数を掛けてすいませんでした


    ありがとうございました m(__)m

解決済み!
引用返信 [メール受信/OFF] 削除キー/
■5493 / inTopicNo.8)  Re[6]: 外部での書き出し時の上書きについて
□投稿者/ 尾形 -(2009/12/27(Sun) 10:12:39)
    うにんさんも以前に書いてあるけど

    >名前の問題じゃないけど、追加書き出しすると長さのあふれた
    >文字列は自動的に捨てられますね。
    >最初に全角2文字を書き出すとcharacter(4)になって、
    >追加で全角4文字書き出すと2文字しか入ってない。
    >データ型のマッピング機能がほしいですね。

    ホントそうだと思いました
    定義値のまま出してくれればいいのに
    結局、事前に自分でテーブル定義が必要なのかな

引用返信 [メール受信/OFF] 削除キー/
■5494 / inTopicNo.9)  Re[6]: 外部での書き出し時の上書きについて
□投稿者/ hidetake -(2009/12/27(Sun) 11:06:33)
    >>lower_case_table_names=1
    > コレで解決しました ^^

    これで解決となると MySQL が桐にとっては、融通の利きやすい
    外部DB と言うことになるのかな?


    > やっぱり単純な事ではないのですね
    > 思いつきで気楽に書いてすいませんでした

    桐の外部DBの問題は、勝手に意味なくテーブル名を大文字や
    小文字に変換してしまう問題があること。また、テーブル名を
    引用符で囲む場所と囲まない場所があり、それらが絡み合って
    変な問題を起こしてしまいます。


引用返信 [メール受信/OFF] 削除キー/
■5495 / inTopicNo.10)  Re[7]: 外部での書き出し時の上書きについて
□投稿者/ hidetake -(2009/12/27(Sun) 11:09:09)
    > 結局、事前に自分でテーブル定義が必要なのかな

    桐の表の状態によって、外部DB側に索引が作られたり、
    作られなかったり。作られたとしても、全く同じ索引を
    複数作ったりしますので、結局、出来たものも手を入れ
    ないといけなかったりします。


引用返信 [メール受信/OFF] 削除キー/



トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

Mode/  Pass/

HOME HELP 新規作成 新着記事 トピック表示 ファイル一覧 検索 過去ログ

- Child Tree -
- Antispam Version -