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

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

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

■5221 / inTopicNo.21)  Re[4]: 外部dbでのロック
  
□投稿者/ 通りすがり -(2009/10/02(Fri) 12:37:26)
    バカンス満喫してキタ-

    おら、オートナンバーは嫌いだど
    従前データ(尾形さんの伝票番号とか)でメインドイし、他との連携(インポート/エクスポート)で不整合生じやすいし
    かといって最大値+1 は、タイミング悪いと重複して再試行必要になることがあるし

    型通り取得と書込みを同時に、桐の#DSQL()でコレ↓なんとか出来る?

    SQL : INSERT INTO 氏名テーブル(ID,氏名) SELECT COALESCE(MAX(ID)+1,1),"小泉純一郎" FROM 氏名テーブル;
引用返信 [メール受信/OFF] 削除キー/
■5222 / inTopicNo.22)  Re[4]: 外部dbでのロック
□投稿者/ うにん -(2009/10/02(Fri) 13:01:18)
    > >>FOR UPDATE
    >
    > 自分の手元の PostgreSQL 7.2 相手に、絞り込み条件
    > #DSQL("id = 20091443) FOR UPDATE;--(")
    > で、抽出してみたけど、他の PC からも 即 訂正可能
    > でした。(^^;

    前に項目訂正のログを見たときCOMMITがあったので、自動的にトランザクションに
    なってると思い込んでた。抽出するだけだからならないですね。
    #DSQLにBEGINだけ入れて何度も再抽出したらこんなログが
    2009-10-02 12:35:21 JSTWARNING: there is already a transaction in progress

    > PostgreSQL 7.2 では、最初の SELECT COUNT(*) 時の
    > FOR UPDATE はエラーを出したけど、次の実際の抽出
    > クエリは実行されたのだけれど・・・
    > # 最初のエラーは集計に FOR UPDATE が付加された
    > # ためで、うにんさんの式とは違うので当然ではあり
    > # ます。ただカウント(エラーが発生しても)されなく
    > # とも次の実際に必要なクエリは実行されるという事。

    pgsql8.4でやったら2ずつ増えないのであれ?と思ったが、なるほど。
    エラーになると同じ行の;の後も実行しないんですね。
    しかし結果が必要ないならなんでわざわざCOUNT(*)してるんだろう^^;
    #DSQLでわざとエラー起こさせて実行しなくさせると再抽出が速くなったりして?

    mysql5.1では集計にFOR UPDATE付けても通ってたわけですね。
    #DSQL("id=1);BEGIN;SELECT * FROM test2 WHERE id=1 FOR UPDATE;UPDATE test2 SET d1=d1+1 WHERE id=1;COMMIT;--")
    pgsqlもこう直したら2ずつ増えた。

    これでやると、桐が表示している値はサーバの値より1少ないということもある。

引用返信 [メール受信/OFF] 削除キー/
■5223 / inTopicNo.23)  Re[5]: 外部dbでのロック
□投稿者/ hidetake -(2009/10/02(Fri) 13:08:30)
    2009/10/02(Fri) 13:10:51 編集(投稿者)

    桐のトランザクション処理(コマンド)と外部DB

    尾形さんのトランザクションのコメントで気になることもあり
    簡単に調べてみた。(PostgreSQL 7.2)

    ---------------------------------------------------------
    変数宣言 整数{&hODBC,&Ret}
    外部DB 接続,ODBC="hoge",ユーザ名="",パスワード="",接続ハンドル=&hODBC,終了状態=&Ret
    トランザクション 開始
    結合 "!hoge.xvw",,変数使用=する,終了状態=&Ret
    表形式編集
    トランザクション ロールバック
    外部DB 切断,&hODBC,終了状態=&Ret
    ---------------------------------------------------------

    と言う簡単な処理でデータを編集してみた。

    やってみて驚いた。「表形式編集」で編集した内容が
    トランザクション ロールバック
    で、ロールバックされ、元のデータに戻っている。

    次に、「表形式編集」状態で、他の PC で外部DBで同じ表を開き、
    編集を行ってみたが、それは可能であった。実際のデータも書き
    換わっていた。
    そして、「表形式編集」のデータを訂正し終了させ、
    そのデータを見てみると、他の PC で変更した内容に戻っていた。
    最初に自分が開いた状態の値(編集前に値)とは異なる。

    PostgreSQL のログを見てみると、

    桐の「トランザクション 開始」コマンドは SQLサーバには何も
    明示的な働きはしていない。(BEGINされない)

    桐の「トランザクション ロールバック」に関しては、桐からの
    ロールバック命令が
    ------------------------------------------------------------
    [12.625]conn=03603AC8, query='UPDATE "hoge" SET "hoge"='1000' WHERE "id"=20091443'
    [14.891]conn=03603AC8, query='ROLLBACK'
    [14.922]conn=03603AC8, PGAPI_Disconnect
    ------------------------------------------------------------
    と 'ROLLBACK' される。

    よく調べてみると、桐の「トランザクション 開始」コマンドはその
    実行時においては、SQLサーバには何も明示的な働きはしていない。
    (BEGINされない)
    トランザクションが開始されるのは、UPDATE 命令が発効される時で
    UPDATE 命令が発生しないときは、「トランザクション ロールバック」
    で query='ROLLBACK' .or query='COMMIT' も無い。

    すなわち、桐でデータを抽出する段階、訂正を行っている最中に
    サーバでデータの書き換えが発生すれば(書き換えることも可能)、
    ロールバックされるデータは、自分の持っているデータでは無く、
    UPDATE 命令が発生される段階のサーバのデータとなる。

    桐で、1行でも訂正(UPDATE)が発生すると、その時点からトランザク
    ション状態となるので、他の PC からはそのデータ(レコード)は
    訂正不可能で待機状態となる。

    と言うことで、桐の「トランザクション」コマンドも外部DBに有効?
    なのですね。ただ、有効になるタイミングは実行したときでは無い
    ので、自分の思っているデータとの整合性は十分に気をつける必要は
    ありそうです。

引用返信 [メール受信/OFF] 削除キー/
■5224 / inTopicNo.24)  Re[5]: 外部dbでのロック
□投稿者/ うにん -(2009/10/02(Fri) 13:09:30)
    > 型通り取得と書込みを同時に、桐の#DSQL()でコレ↓なんとか出来る?
    >
    > SQL : INSERT INTO 氏名テーブル(ID,氏名) SELECT COALESCE(MAX(ID)+1,1),"小泉純一郎" FROM 氏名テーブル;

    2回実行されるので、氏名が重複禁止になってれば問題ないのでは。

引用返信 [メール受信/OFF] 削除キー/
■5225 / inTopicNo.25)  Re[1]: 外部dbでのロック
□投稿者/ うにん -(2009/10/02(Fri) 13:40:32)
    > 自分は年度別に伝票番号をつけています
    > 主キー(id)とは別に管理したいと思っています
    >
    > 伝票番号を管理するテーブルから番号を+1して
    > 取得しようとする処理を考えた場合に困ってしまいました

    このテーブルってレコードは常に1行しかないわけですよね?
    [伝番]を主キーにすれば、ロックしないでも訂正時にチェックされるので

    繰り返し
     結合  "伝番更新用.XVW",,表番号=2
     行訂正 終了状態=&秒,[id]=[id]+1
     代入  &伝番=[伝番]
     条件 (&秒=1) 繰り返し中止
    繰り返し終了

    でよくないですか?
引用返信 [メール受信/OFF] 削除キー/
■5226 / inTopicNo.26)  Re[6]: 外部dbでのロック
□投稿者/ hidetake -(2009/10/02(Fri) 13:40:42)
    2009/10/02(Fri) 13:43:55 編集(投稿者)

    > 桐のトランザクション処理(コマンド)と外部DB

    > よく調べてみると、桐の「トランザクション 開始」コマンドはその
    > 実行時においては、SQLサーバには何も明示的な働きはしていない。
    > (BEGINされない)
    > トランザクションが開始されるのは、UPDATE 命令が発効される時で
    > UPDATE 命令が発生しないときは、「トランザクション ロールバック」
    > で query='ROLLBACK' .or query='COMMIT' も無い。
    >
    > すなわち、桐でデータを抽出する段階、訂正を行っている最中に
    > サーバでデータの書き換えが発生すれば(書き換えることも可能)、
    > ロールバックされるデータは、自分の持っているデータでは無く、
    > UPDATE 命令が発生される段階のサーバのデータとなる。
    >
    > 桐で、1行でも訂正(UPDATE)が発生すると、その時点からトランザク
    > ション状態となるので、他の PC からはそのデータ(レコード)は
    > 訂正不可能で待機状態となる。
    >
    > と言うことで、桐の「トランザクション」コマンドも外部DBに有効?
    > なのですね。ただ、有効になるタイミングは実行したときでは無い
    > ので、自分の思っているデータとの整合性は十分に気をつける必要は
    > ありそうです。
    >

    もう少し調べてみると、「トランザクション」コマンドを入れても
    入れなくても、BEGIN は発生しており、これが自動トランザクションか
    桐の処理か良くわからなかったけど、どうも桐の直接の命令では無い
    らしい。

    PostgreSQL の場合だけかは良くわからないけど、
    桐は「自動コミット」パラメータを設定変更して、トランザクションを
    コントロールしているようだ。

    UPFATE をかける前に
    [1736-12.204]PGAPI_SetConnectOption: AUTOCOMMIT: transact_status=1, vparam=0
    [1736-12.204]CC_set_autocommit: 1->0
    と、autocommit をオフにし、UPDATE をかける。

    「トランザクション 開始」命令が無いときには、桐は自分で
    query='COMMIT' を実行する。
    これは、UPDATE が発生するたびに繰り返される。

    「トランザクション 開始」命令があるときには、UPDATE が
    発生しても、桐はその都度は query='COMMIT' を発行しない。
    「トランザクション コミット」もしくは
    「トランザクション ロールバック」があったときに初めて
    query='COMMIT' .or query='ROLLBACK' が実行される。

    query='COMMIT' .or query='ROLLBACK' が実行されると
    [1736-12.235]PGAPI_SetConnectOption: AUTOCOMMIT: transact_status=0, vparam=1
    [1736-12.235]CC_set_autocommit: 0->1
    と、autocommit パラメータを元に戻している。


    ほかの DB では、どんなトランザクション制御をしているだ
    ろうか!?

引用返信 [メール受信/OFF] 削除キー/
■5227 / inTopicNo.27)  Re[6]: 外部dbでのロック
□投稿者/ 尾形 -(2009/10/02(Fri) 13:53:02)
    どうも、こんにちは

    不思議な現象?です
    (全てマニュアル手動操作です)
    PC1側とPC2側の両方で同じテーブルを開きます
    どちらも、同じある1行だけを絞り込みします
    (当然2台とも同じ値が表示されています)

    PC1側で
    ある数値項目で[置換(F2)]で []+1 を置換実行

    PC2側で(再抽出せずに、古いままの値の状態で)
    同じように[置換(F2)] []+1 を置換実行すると
    「一意のキーは・・・・」みたいなメッセージがでて
    受け付けてくれません
    []+2なら通してくれます
    置換ではなく値を直接手入力も通してくれます

    ドライバ側かな?

引用返信 [メール受信/OFF] 削除キー/
■5228 / inTopicNo.28)  Re[2]: 外部dbでのロック
□投稿者/ 尾形 -(2009/10/02(Fri) 14:07:09)
    > このテーブルってレコードは常に1行しかないわけですよね?
    [年度][伝番]があります
    先日付の入力がありますので

    > [伝番]を主キーに
    主キーを書き換える発送ですね
    思いつきませんでした

    でも、かぶった場合大丈夫ですかねぇ
    検証してみます

引用返信 [メール受信/OFF] 削除キー/
■5229 / inTopicNo.29)  Re[7]: 外部dbでのロック
□投稿者/ うにん -(2009/10/02(Fri) 15:32:31)
    > ほかの DB では、どんなトランザクション制御をしているだ
    > ろうか!?

    MySQL5.1でも同じようでした。サーバーログでこんな感じ。
    外部DBの結合
    15 Query SELECT COUNT(*) FROM `test2` WHERE ...
    15 Query SELECT `t`,`id`,`denban` FROM `test2` ...
    行訂正
    15 Query SET AUTOCOMMIT=0
    15 Query UPDATE `test2` SET `id`=6 WHERE `id`=5
    トランザクション コミット
    15 Query COMMIT
    15 Query SET AUTOCOMMIT=1
引用返信 [メール受信/OFF] 削除キー/
■5230 / inTopicNo.30)  Re[8]: 外部dbでのロック
□投稿者/ hidetake -(2009/10/02(Fri) 15:45:09)
    > MySQL5.1でも同じようでした。サーバーログでこんな感じ。
    > 外部DBの結合
    > 15 Query SELECT COUNT(*) FROM `test2` WHERE ...
    > 15 Query SELECT `t`,`id`,`denban` FROM `test2` ...
    > 行訂正
    > 15 Query SET AUTOCOMMIT=0
    > 15 Query UPDATE `test2` SET `id`=6 WHERE `id`=5
    > トランザクション コミット
    > 15 Query COMMIT
    > 15 Query SET AUTOCOMMIT=1

    AUTOCOMMIT って、ほとんどの DB で一緒のようですね。

    桐の表編集など(フォームだろうが一緒)を使って、会話的に
    使うところで、桐のトランザクション処理に頼ると、直ぐに
    デッドロックを起こしてしまいそうですね。
    試しにやってみると簡単です。
    ただ、DB のデッドロック検出が働くので直ぐにエラーが
    発生し、止まってくれますが! (^^;

引用返信 [メール受信/OFF] 削除キー/
■5231 / inTopicNo.31)  Re[6]: 外部dbでのロック
□投稿者/ うにん -(2009/10/02(Fri) 17:00:47)
    >>型通り取得と書込みを同時に、桐の#DSQL()でコレ↓なんとか出来る?
    >>
    >>SQL : INSERT INTO 氏名テーブル(ID,氏名) SELECT COALESCE(MAX(ID)+1,1),"小泉純一郎" FROM 氏名テーブル;
    >
    > 2回実行されるので、氏名が重複禁止になってれば問題ないのでは。

    MySQL5.1で氏名に重複禁止索引を作ってやってみました。
    #DSQL("1);INSERT INTO names(id,name) SELECT COALESCE(MAX(id)+1,1),&STR FROM names;--")

    INSERTする値が変えられないと困るので、&STRに代入して使います。
    #DSQLの引数は文字列定数なのに項目名や変数名は処理してからサーバに送られるのでややこしい。
    変数名は何も付けないで""の中に書くと自動的に'変数値'になっていました。

    pgsqlでは;の後の結果は桐から無視されてるような感じだったが、
    MySQLだとINSERTした行もすぐ見える。

    ただ、私のところは日本語設定がおかしいようでテーブル・列名に日本語使うと桐で??になってしまう。
    上のINSERTでは変数値は日本語OK(サーバには入ってる)だがその行だけ抽出されない^^;;

引用返信 [メール受信/OFF] 削除キー/
■5232 / inTopicNo.32)  Re[7]: 外部dbでのロック
□投稿者/ 通りすがり -(2009/10/02(Fri) 19:44:06)
    &STR が使えるとは大発見!! ドウモ
    でも、おらの頭の中はウニ状態で何が何だか訳ワカメ、根気無くなっているのが自分で解る
    年取ったなぁ
引用返信 [メール受信/OFF] 削除キー/
■5233 / inTopicNo.33)  Re[7]: 外部dbでのロック
□投稿者/ 通りすがり -(2009/10/02(Fri) 21:32:08)
    SQLサーバーでも、直ぐに追加レコード"小泉純一郎"が見えた、でも、次の”沢尻エリカ"追加で、"小泉純一郎"が2行になる(見えなかったもう1行も再抽出)
    ああ、simeiにユニーク設定し忘れてたorz
    また、しばらく離れて弄れない…
引用返信 [メール受信/OFF] 削除キー/
■5236 / inTopicNo.34)  Re[8]: 外部dbでのロック
□投稿者/ うにん -(2009/10/03(Sat) 12:43:01)
    > SQLサーバーでも、直ぐに追加レコード"小泉純一郎"が見えた、でも、次の”沢尻エリカ"追加で、"小泉純一郎"が2行になる(見えなかったもう1行も再抽出)
    > ああ、simeiにユニーク設定し忘れてたorz

    あ、そうか。2回実行されてるから1回目のCOUNT(*)の時にINSERTされてるんだ。
    2回目のデータ取得のと同時にINSERTされてるのが見えたわけじゃなかった。

引用返信 [メール受信/OFF] 削除キー/
■5246 / inTopicNo.35)  Re[5]: オートナンバー嫌い
□投稿者/ 尾形 -(2009/10/05(Mon) 07:16:05)
    > オートナンバーは嫌いだど
    「簡単で便利いいのに」と思っていましたけど
    桐得意の一覧表形式だと不便ですね

    行追加入力していて「入力間違えた」となった場合
    (再抽出しないと)修正が出来ないですね
    これは入力者から蹴られそうだな


    # 端末毎に自前でオートナンバーをふるかな

引用返信 [メール受信/OFF] 削除キー/
■5496 / inTopicNo.36)  Re[1]: MySQLでのロック
□投稿者/ 尾形 -(2009/12/28(Mon) 07:58:17)
    常識なのかもしれませんけど

    http://blog.livedoor.jp/sasata299/archives/51345903.html
    >ユニーク制約 or インデックスカラムで検索、行ロック
    >それ以外のカラムで検索した場合、テーブルロック

    なんか以外?でしたので
    桐側で適当に抽出したら、テーブルロック
    しまくりって事ですよね

引用返信 [メール受信/OFF] 削除キー/
■5497 / inTopicNo.37)  Re[2]: MySQLでのロック
□投稿者/ 尾形 -(2009/12/28(Mon) 08:01:06)
    セレクトだけならいいのかしら?

    そうですよね

引用返信 [メール受信/OFF] 削除キー/
■5498 / inTopicNo.38)  Re[3]: MySQLでのロック
□投稿者/ うにん -(2009/12/28(Mon) 09:04:25)
http://chart.apis.google.com/chart?cht
    No5497に返信(尾形さんの記事)
    > セレクトだけならいいのかしら?
    >
    > そうですよね

    UPDATEの話ですね。
    それに、uniqueもindexだから「ユニーク制約 or インデックスが張られているカラム」ってちょっと変。
引用返信 [メール受信/OFF] 削除キー/
■5499 / inTopicNo.39)  Re[4]: MySQLでのロック
□投稿者/ 尾形 -(2009/12/28(Mon) 13:20:26)
    > UPDATEの話ですね。
    失礼しました
    基本からよく勉強しなおします

引用返信 [メール受信/OFF] 削除キー/
■5615 / inTopicNo.40)  SELECT COUNT(*)
□投稿者/ 尾形 -(2010/02/13(Sat) 18:16:39)
    SELECT COUNT(*)が目障りだなぁと思ってたけど

    桐の環境設定で「データ抽出時の情報表示」を無し
    に設定したらなくなりました
    当然かもしれないけど (^^;

    ちょっと嬉しい ^^

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

<前の20件 | 次の20件>

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

[このトピックに返信]
Mode/  Pass/

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

- Child Tree -
- Antispam Version -