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

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

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

■5013 / inTopicNo.1) 　外部DBの表示更新
  ▼■
□投稿者/ うにん -(2009/08/25(Tue) 16:08:40)
    環境設定で「再表示の間隔」設定しても自動更新されません。なんでだろ。
    「実表を更新する外部データベース」です。共有で開いてもだめだった。

    pgsql側でデータ変更した後、桐で再抽出せずに項目編集すると的外れなメッセージが出て保存できない。
    KD1672:ODBC ｴﾗｰ
    "外部DBテーブル名" 表の更新ﾚｺｰﾄﾞ数は 0 行です
    主キーまたは一意索引の値が変更または削除されています
    これも「項目訂正時とカーソル移動時の処理対象項目は、つねに最新の情報が表示されます。」が実行されてないのでそうなる。

    あ、桐同士での変更しか反映されないのか！？しかし
    外部DBなのに桐からの変更しか感知しないというのも変だよなあ。
引用返信 [メール受信/OFF] 削除キー/
■5015 / inTopicNo.2) 　Re[1]: 外部DBの表示更新
□投稿者/ hidetake -(2009/08/25(Tue) 16:54:51)
    2009/08/25(Tue) 17:08:02 編集(投稿者)

    この辺は、Access の「テーブルのリンク」だって似たようなものだと
    思います。

    ただ、桐の場合は、条件に合うデータを一度に全部持ってきて、桐内部
    に保持しますが、Access の場合は一度に全部ではなく、表示されている
    レコードの付近をある程度のバッファ容量だけ持ってくるようです。
    なので、レコード件数が多い場合は、レコードの移動により、行って戻
    ってくると、最新のデータに変わっている場合もあります。桐は明示的に
    「結合表の再抽出」を行った場合のみ最新のデータを取り直してきます。

    あと、データの編集で異なるのは、もちろん、桐も Access も最新の
    データのことなど考慮しませんが、桐の場合は、何の条件もなく UPDATE
    をかけます。なので、サーバ側の特別の条件に引っかからない限り、最新
    のデータなど関係ないし自分のデータで UPDATE しますが、Access は
    抽出した段階のデータを「WHERE句」の条件としてくっつけて SQL を
    投げかけます。なので、抽出した項目の１項目でも自分が抽出したときと
    値が異なっていたら、データが更新されているとエラーが発生されます。


    今回のエラーは索引の関係で、桐が UPDATE した内容と整合性が保て無く
    なっていたのだと思います。



    一部編集
    > 表示されているレコードの付近をある程度のバッファ容量だけ持って
    > くるようです。

    コレって、やはり変かな？　ある一定レコード数なのかな。


引用返信 [メール受信/OFF] 削除キー/
■5016 / inTopicNo.3) 　Re[2]: 外部DBの表示更新
□投稿者/ うにん -(2009/08/25(Tue) 17:39:21)

    > あと、データの編集で異なるのは、もちろん、桐も Access も最新の
    > データのことなど考慮しませんが、桐の場合は、何の条件もなく UPDATE
    > をかけます。なので、サーバ側の特別の条件に引っかからない限り、最新
    > のデータなど関係ないし自分のデータで UPDATE しますが、Access は
    > 抽出した段階のデータを「WHERE句」の条件としてくっつけて SQL を
    > 投げかけます。なので、抽出した項目の１項目でも自分が抽出したときと
    > 値が異なっていたら、データが更新されているとエラーが発生されます。

    桐も9-2009では既存値を見ています。ODBCのトレースで
    未定義の項目にデータを入力すると
    "UPDATE public."table" SET "\ff\ff\ff\ff\ff\ff"=? WHERE "\ff\ff\ff\ff\ff\ff" IS NULL AND "pkey"=?"
    既存値の変更だと
    "UPDATE public."table" SET "\ff\ff\ff\ff\ff\ff"=? WHERE "\ff\ff\ff\ff\ff\ff"=? AND "pkey"=?"
    でparamが3つになる。

    さっきのエラーは桐が自分の持ってる既存値を検索条件にいれてて見つからないので編集できなかったというケースなのです。
引用返信 [メール受信/OFF] 削除キー/
■5017 / inTopicNo.4) 　Re[3]: 外部DBの表示更新
□投稿者/ hidetake -(2009/08/25(Tue) 18:04:32)
    > 桐も9-2009では既存値を見ています。ODBCのトレースで
    > 未定義の項目にデータを入力すると
    > "UPDATE public."table" SET "\ff\ff\ff\ff\ff\ff"=? WHERE "\ff\ff\ff\ff\ff\ff" IS NULL AND "pkey"=?"
    > 既存値の変更だと
    > "UPDATE public."table" SET "\ff\ff\ff\ff\ff\ff"=? WHERE "\ff\ff\ff\ff\ff\ff"=? AND "pkey"=?"
    > でparamが3つになる。

    この WHERE句 って抽出条件では無いのですか？

    コレって相当前に調べたことだけれど、再度、手元で
    調べたら何も変わっていないようでした。
    別の PC で書き換えあとで UPDATE しても、何のエラー
    もなく自分のデータで書き換えてくれましたけど。

    "別"=2 の状態で 2台の PC で抽出。
    別の PC で 1 に書き換えたあと、もう１台で 3 に
    書き換えた場合、

    'UPDATE "reikai" SET "別"='3' WHERE "id"=20091402'

    と、最初の抽出条件の "id"=20091402 はついているけど
    "別"='2' は WHERE句には付加されていません。
    これ以外にも一杯項目はあるのですけど・・・

    これは PostgreSQL に限ってテストしたわけでも無かっ
    たと記憶しているのですが。

引用返信 [メール受信/OFF] 削除キー/
■5018 / inTopicNo.5) 　Re[4]: 外部DBの表示更新
□投稿者/ うにん -(2009/08/25(Tue) 20:04:07)
    >>桐も9-2009では既存値を見ています。ODBCのトレースで
    >>未定義の項目にデータを入力すると
    >>"UPDATE public."table" SET "\ff\ff\ff\ff\ff\ff"=? WHERE "\ff\ff\ff\ff\ff\ff" IS NULL AND "pkey"=?"
    >>既存値の変更だと
    >>"UPDATE public."table" SET "\ff\ff\ff\ff\ff\ff"=? WHERE "\ff\ff\ff\ff\ff\ff"=? AND "pkey"=?"
    >>でparamが3つになる。
    >
    > この WHERE句 って抽出条件では無いのですか？

    そうです。pkeyが主キーで、それの前にANDで古い値を渡して
    変更されてなかった場合だけUPDATEするようにしているわけですよね。

    > コレって相当前に調べたことだけれど、再度、手元で
    > 調べたら何も変わっていないようでした。
    > 別の PC で書き換えあとで UPDATE しても、何のエラー
    > もなく自分のデータで書き換えてくれましたけど。
    >
    > "別"=2 の状態で 2台の PC で抽出。
    > 別の PC で 1 に書き換えたあと、もう１台で 3 に
    > 書き換えた場合、
    >
    > 'UPDATE "reikai" SET "別"='3' WHERE "id"=20091402'
    >
    > と、最初の抽出条件の "id"=20091402 はついているけど
    > "別"='2' は WHERE句には付加されていません。

    こちらでやったのは、別のPCは桐を使わずpgAdmin3などで変更しています。
    そのせいで他の変更が取得できてないのかと思ったのですが、そうでもない？
    「3に書きかえる」とき、項目編集に入ったら最新データ=1になってくれるのが
    HELPの記述ですよね。この点はどうでしょうか。
    これは表示の更新間隔を「0＝自動更新なし」にしないとそうならないのかなあ。

    ちなみに私のトレースの項目名が\ffだらけになってるのは、伏字にしたのでなく
    元々こうなのです。何か変。
    あと、prepareとbinddataが使われてるので、hidetakeさんの例のような即値の
    SQLにはなってません。bindの部分はデータ長とポインタしかログされてなくて、
    実際のデータが見えません^^;;;
引用返信 [メール受信/OFF] 削除キー/
■5019 / inTopicNo.6) 　Re[5]: 外部DBの表示更新
□投稿者/ hidetake -(2009/08/25(Tue) 22:19:20)
    2009/08/25(Tue) 22:36:37 編集(投稿者)

    > こちらでやったのは、別のPCは桐を使わずpgAdmin3などで変更しています。
    > そのせいで他の変更が取得できてないのかと思ったのですが、そうでもない？
    > 「3に書きかえる」とき、項目編集に入ったら最新データ=1になってくれるのが
    > HELPの記述ですよね。この点はどうでしょうか。
    > これは表示の更新間隔を「0＝自動更新なし」にしないとそうならないのかなあ。

    コレって HELP の中の
    > [再表示の間隔]
    > 表を共有するとき、何秒ごとに最新の情報に更新するかを指定します。
    > 実表を更新する結合表と外部データベース、参照整合性で関連づけら
    > れた表の編集でも、同じ間隔で更新されます。指定できる間隔は１秒
    > から 1000 秒までです。一定間隔ごとに更新する必要がない場合は
    > ゼロを指定します。
    > 更新する間隔を短くすると、頻繁にアクセスするようになるため、
    > コンピュータとネットワークの負荷が大きくなりますので注意して
    > ください。更新する間隔をゼロにしても、つぎの場面では自動的に
    > 最新の情報に更新されます。
    >
    > 画面スクロール
    > 表を更新した後
    > 編集対象表の切り替え
    > 項目訂正時とカーソル移動時の処理対象項目は、つねに最新の情報が
    > 表示されます。

    の事ですね。
    > 実表を更新する結合表と外部データベース
    が記載されているのは、初めて知りました。

    自分の設定は 5秒ですが、外部DBで自動的に更新された覚えはありません
    けど・・・

    試しに 1秒にしたけど、1秒待っても 30秒待っても「結合表の再抽出」を
    実行しない限り表示データは更新されないようですけど。


    追加
    桐v8 の(紙の)マニュアルにも
    > 実表を更新する結合表と外部データベース
    は、ちゃんと記載されていました。
    と、言うことは読んだことはあるのだろうけど、自動更新(再抽出)された
    覚えは1度もありません。

    自動更新されたところで、訂正モードに入ってからサーバ側が更新されて
    そのデータが反映されることは無いので、だからどうだとも言えないとは
    思いますが。

引用返信 [メール受信/OFF] 削除キー/
■5020 / inTopicNo.7) 　Re[5]: 外部DBの表示更新
□投稿者/ hidetake -(2009/08/26(Wed) 08:32:37)
    > ちなみに私のトレースの項目名が\ffだらけになってるのは、
    > 伏字にしたのでなく元々こうなのです。何か変。

    この形式の表記は見たような気もしたけど、これは ODBC の
    トレースの中身のようですね。(SQL.LOG)

    私の書いたのは、今回は PostgreSQL 相手だったので PostgreSQL
    の ODBC ドライバにログをはき出すように設定し、その中身です。
    psqlodbc_xxxx.log
    mylog_xxxx.log


引用返信 [メール受信/OFF] 削除キー/
■5021 / inTopicNo.8) 　Re[6]: 外部DBの表示更新
□投稿者/ うにん -(2009/08/26(Wed) 12:00:10)

    > 自分の設定は 5秒ですが、外部DBで自動的に更新された覚えはありません
    > けど・・・
    >
    > 試しに 1秒にしたけど、1秒待っても 30秒待っても「結合表の再抽出」を
    > 実行しない限り表示データは更新されないようですけど。

    やっぱりそうですかあ。バグっぽいなあ。

    > 自動更新されたところで、訂正モードに入ってからサーバ側が更新されて
    > そのデータが反映されることは無いので、だからどうだとも言えないとは
    > 思いますが。

    訂正前に一々再抽出しないでいいだけで、ずいぶん操作性が違うと思います。
    保存できない（そちらではできてるようですが）とわかってるのに
    無駄な編集する危険性も減りますよね。
    訂正モードに入った時サーバをロックできれば完璧かなあ。
引用返信 [メール受信/OFF] 削除キー/
■5022 / inTopicNo.9) 　Re[6]: 外部DBの表示更新
□投稿者/ うにん -(2009/08/26(Wed) 12:50:51)
    >>ちなみに私のトレースの項目名が\ffだらけになってるのは、
    >>伏字にしたのでなく元々こうなのです。何か変。
    >
    > この形式の表記は見たような気もしたけど、これは ODBC の
    > トレースの中身のようですね。(SQL.LOG)

    そうです。

    > 私の書いたのは、今回は PostgreSQL 相手だったので PostgreSQL
    > の ODBC ドライバにログをはき出すように設定し、その中身です。
    > psqlodbc_xxxx.log
    > mylog_xxxx.log

    なるほど、こっちにもあるのですね。（設定画面ではc:\になってるけどVistaの
    せいか実際は自分のディレクトリにできていた。）

    mylog〜を見るとparamが埋め込まれた状態がわかりました。
    例えば未定義値の項目を項目訂正するとき
    [220-1014.779] stmt_with_params = 'UPDATE public."tablename" SET "項目名"=E'12:24' WHERE "項目名" IS NULL AND "ｺｰﾄﾞ"=E'06017''
    やっぱり私のとこではデータが変更されてないかチェックしてます。
    変更されてると「主キーまたは一意索引」じゃなくて変更しようとした項目が
    変更されてるんだけど、エラーになって保存できない。一旦編集を破棄して
    再抽出してから編集しなおす必要があります。
    項目訂正ならコピペできるからまだいいけど、行訂正だと悲惨。

    と思って行訂正のログを見たら、WHEREに条件が追加されてない。何と。
    桐から書き出したtableで、先頭の項目がサーバ側では単なるcharacterなのに
    外部DB定義したときなぜか勝手に主キー扱いになってました。
    全然uniqueじゃないのに？
引用返信 [メール受信/OFF] 削除キー/
■5023 / inTopicNo.10) 　Re[7]: 外部DBの表示更新
□投稿者/ 通りすがり -(2009/08/26(Wed) 13:13:54)
    > やっぱりそうですかあ。バグっぽいなあ。

    表を共有する時の設定だから
    外部データベースの表を複数台で共有して、1台で表更新すると、他のPCの表が仕様どおりに更新再表示されるのでは？
    ODBC接続先データからの更新反映は別の話しかと
引用返信 [メール受信/OFF] 削除キー/
■5024 / inTopicNo.11) 　Re[8]: 外部DBの表示更新
□投稿者/ hidetake -(2009/08/26(Wed) 14:26:33)
    >>やっぱりそうですかあ。バグっぽいなあ。
    >
    > 表を共有する時の設定だから
    > 外部データベースの表を複数台で共有して、1台で表更新すると、他のPCの表が仕様どおりに更新再表示されるのでは？
    > ODBC接続先データからの更新反映は別の話しかと

    .XVW を複数台で共有しても、別に他の PC の表示が更新されることも
    無いようですけど。


引用返信 [メール受信/OFF] 削除キー/
■5025 / inTopicNo.12) 　Re[9]: 外部DBの表示更新
□投稿者/ 通りすがり -(2009/08/26(Wed) 14:32:32)
    > .XVW を複数台で共有しても、別に他の PC の表示が更新されることも
    > 無いようですけど。

    ああ、御確認有難うございます<m(__)m>
    単に仕様の読み違えかと思って…書いてから今確認中

    拙速、ゴメンネ >> うにん さん

引用返信 [メール受信/OFF] 削除キー/
■5027 / inTopicNo.13) 　Re[2]: 外部DBの表示更新
□投稿者/ hidetake -(2009/08/27(Thu) 10:05:50)
    2009/08/27(Thu) 10:08:50 編集(投稿者)

    一部編集
    >>表示されているレコードの付近をある程度のバッファ容量だけ持って
    >>くるようです。
    >
    > コレって、やはり変かな？　ある一定レコード数なのかな。
    >

    Access2003 で確認したら、Access は最初に主キーの項目をデータ
    を全て取得する。その取得した主キーの値で 10件ずつ WFERE句に
    条件として OR でつなげて SELECT していました。10件は条件に
    よって変わるかも知れないし、その取得したデータを Access 内部
    でどれぐらい保持しているのかも変わってくるのかも知れません。

    UPDATE に関しては、取得した項目の最初の値を全て WHERE句の条件
    として AND としてつなげて、取得した時点のデータと変更が無い
    事を条件として UPDATE をかけるのは以前調べたのと同じでした。


    外部DB としては 1998年に PostgreSQL や InterBase 相手に接続し
    だしましたが、桐も Access もその当時からほとんど何も変わって
    いないと思います。桐は当時 桐v7 ですが。
    桐は最初に全てのデータを取得する。Access はスクロール等の必要
    に応じ都度データを取得する。
    そして、どちらも、一度表示されたデータ&編集したデータは、明示
    的に再抽出(最新の情報に更新)しなければ、サーバからのデータは
    取り直さない。

引用返信 [メール受信/OFF] 削除キー/
■5029 / inTopicNo.14) 　Re[3]: 外部DBの表示更新
□投稿者/ うにん -(2009/08/28(Fri) 14:03:17)

    > そして、どちらも、一度表示されたデータ&編集したデータは、明示
    > 的に再抽出(最新の情報に更新)しなければ、サーバからのデータは
    > 取り直さない。

    なるほど。FileMakerも同じようでした。
    HELPの記述が間違ってるということですね。

    あとは、外部DB定義時に先頭の項目に勝手に鍵マークが付く現象を調べます。

引用返信 [メール受信/OFF] 削除キー/
■5030 / inTopicNo.15) 　Re[4]: 外部DBの表示更新
□投稿者/ うにん -(2009/08/28(Fri) 16:55:05)
    > あとは、外部DB定義時に先頭の項目に勝手に鍵マークが付く現象を調べます。

    テーブルに主キーがあると常に先頭のカラムも鍵マークがついている。
    そのカラムを削除すると先頭になったカラムに鍵マークがつく。
    別に害はなさそうだけど...
引用返信 [メール受信/OFF] 削除キー/


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

このトピックに書きこむ

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

Mode/　 Pass/

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

- Child Tree -
- Antispam Version -