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

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

[ 親記事をトピックトップへ ]

このトピックに書きこむ

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

■7417 / inTopicNo.1)  Re[11]: SQL Server の IDENTITY について
  
□投稿者/ そら -(2013/01/29(Tue) 13:56:29)
    今村さん、ありがとうございます。
    とても勉強になりました。
引用返信 [メール受信/OFF] 削除キー/
■7416 / inTopicNo.2)  Re[10]: SQL Server の IDENTITY について
□投稿者/ 今村 誠 -(2013/01/29(Tue) 09:37:38)
    そらさんこんにちは
    > なお、行番号を付加する目的は、「読み込み」も使えるようにする事でした。
    > つまり読み込みの場合は、全く同一の日時値で複数行追加されるリスクが
    > 想定された訳です。

    何から読む込むのか書いてありませんが、csvやアクセスのデータから
    一度桐の表に変換して、外部データベース用に加工してから、通常使用
    する外部データ表とするのがいいのではないでしょうか。

    2つ前のコメント No7371 の手続き名でいえば行挿入の日時値を関数で
    なく日時値加算を使い「0.1秒」毎に加算していけば1分で600件が
    1時間で36000件が8時間で288000件が1PCや1ユーザー名で追加可能で
    あり、22時の深夜や休日祭日に初期値を設定すればいつでも読み込みは
    可能です。
    通常の業務で支障なければ一番理想的な主キーになるのではないですか。
引用返信 [メール受信/OFF] 削除キー/
■7415 / inTopicNo.3)  Re[9]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/28(Mon) 21:11:54)
    2013/01/28(Mon) 21:13:54 編集(投稿者)

    今村さん、ご指摘ありがとうございます。

    ユーザーの表を使う前提なのですね。勉強になりました。
    ただ、私としてはユーザ名よりはコンピュータ名の方が、
    同一のサブネット内での重複が避けられる点で安全性が高いと考えました。
    無論、IPセグメントを越える様な規模では無意味なのですが。

    可読性と用心のために、かなり冗長な文字列になってしまっているのは、
    まさにおっしゃる通りです。まだまだ改善が必要ですね。

    なお、行番号を付加する目的は、「読み込み」も使えるようにする事でした。
    つまり読み込みの場合は、全く同一の日時値で複数行追加されるリスクが
    想定された訳です。
引用返信 [メール受信/OFF] 削除キー/
■7398 / inTopicNo.4)  Re[1]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/23(Wed) 21:00:42)
    みなさん、ありがとうございました。

    おかげさまで、非常に勉強になりました。

    今後もぜひよろしくお願いします。
解決済み!
引用返信 [メール受信/OFF] 削除キー/
■7395 / inTopicNo.5)  Re[3]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/23(Wed) 14:37:53)
    通りすがりさん、ありがとうございます。

    データーベースサーバーとはそういうものなのですね。理解しました。
引用返信 [メール受信/OFF] 削除キー/
■7393 / inTopicNo.6)  Re[2]: SQL Server の IDENTITY について
□投稿者/ 通りすがり -(2013/01/23(Wed) 08:39:53)
    そういう事が無いように順序立てて処理する仕組みがデータベースサーバー
    もし万々々が一の時は、主キーなんだからエラー出るでしょ

    INTEGER使うなら「サーバ側でID振って、桐側で必要時に再抽出する」に一票

    つーか、主キーはCHARで問題ないとオモ
引用返信 [メール受信/OFF] 削除キー/
■7391 / inTopicNo.7)  Re[11]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/23(Wed) 07:37:17)
    尾形さん、ありがとうございます。

    > だから
    >>シビアな状況でなければ、お手軽に
    > というわけです (^^;

    そういう意味だったのですね。理解しました。


    > ちなみに、バッティングしたら
    > 桐(ODBC)から、エラーメッセージが返ってくるようで
    > [再試行]で再繰上されています

    INSERTとUPDATEがきちんと区別されるのですね。
    アドバイス、ありがとうございます。


    > シビアな状況では、別テーブルで、端末毎に
    > 自前でオートナンバを振っています

    サーバー上に1つだけの別テーブルを専有で開くわけですね。
引用返信 [メール受信/OFF] 削除キー/
■7389 / inTopicNo.8)  Re[10]: SQL Server の IDENTITY について
□投稿者/ 尾形 -(2013/01/22(Tue) 21:48:15)
    だから
    > シビアな状況でなければ、お手軽に
    というわけです (^^;

    ちなみに、バッティングしたら
    桐(ODBC)から、エラーメッセージが返ってくるようで
    [再試行]で再繰上されています



    シビアな状況では、別テーブルで、端末毎に
    自前でオートナンバを振っています

引用返信 [メール受信/OFF] 削除キー/
■7388 / inTopicNo.9)  Re[1]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/22(Tue) 20:41:26)
    ご丁寧にお答えくださり、皆さんありがとうございます。
    すみませんが、もう1つ伺いたいことがあります。
    
    
    INSTEAD OF INSERTトリガが同時に複数、多重実行される可能性はあるのでしょうか?
    
    もしそのような場合、下記の定義では[ID]が重複してしまうと思うのですが、
    その様な状況を回避することは可能でしょうか?
    
    SQL Serverの処理速度から推測して、発生確率は低いと思われるのですが、
    リスクはあるように思えます。
    
    たびたびお手数をお掛けしますが、お願いします。
    
    
    > CREATE TRIGGER InsteadOfInsert on テスト表
    > INSTEAD OF INSERT AS BEGIN 
    > 	INSERT INTO テスト表( 
    > 		[ID],
    > 		[項目1],
    > 		[項目2]
    > 	)
    > 	SELECT
    > 		[newID],
    > 		[項目1],
    > 		[項目2]
    > 	FROM
    > 		inserted,
    > 		(select
    > 			case
    > 				when max( [ID] ) is null then 1
    > 				else max( [ID] ) + 1
    > 			end as [newID]
    > 		from	テスト表)a
    > END;

引用返信 [メール受信/OFF] 削除キー/
■7386 / inTopicNo.10)  Re[9]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/22(Tue) 17:49:30)
    2013/01/22(Tue) 17:58:21 編集(投稿者)

    尾形さん、ご丁寧にありがとうございます。

    > 同一テーブルからMAX取ってきます

    ということは、やはり同時複数アクセスで、[ID]がコリジョンするリスクがないでしょうか?

    つまりある端末が、行挿入終了前のイベント処理をしている間に、
    別の端末が同様に行挿入終了前のイベント処理を開始して、MAX( ID )を取得すると、
    両方の端末で重複した [ID] が設定されてしまい、先に行追加が完了した方のレコードが、
    消えてしまわないかということです。


    > 動的にテーブルも項目も変更できます

    SQLインジェクションを使うわけですね。
    一段落しましたら、勉強させて頂きます。
引用返信 [メール受信/OFF] 削除キー/
■7385 / inTopicNo.11)  Re[9]: SQL Server の IDENTITY について
□投稿者/ 尾形 -(2013/01/22(Tue) 16:43:42)
    ちょっと補足

    &STR = " '" + \
        ",`得意先名`" + \
        ",`住所`" + \
        " FROM `mst_tokui`" + \
        " WHERE `ID` = 123" + \
        " ; -- "
    結合 "ダミー.xvw"・・・
    これで、[項目1]に得意先名、[項目2]に住所が入ります
    (得意先IDは123指定)


    &STR = " '" + \
        ",MAX( `伝票ID` )" + \
        " FROM `denpyo_meisai`" + \
        " ; -- "
    結合 "ダミー.xvw"・・・
    これで、[項目1]にdenpyo_meisaiテーブルのMAX(`伝票ID`)
    が入ります


    動的にテーブルも項目も変更できます

引用返信 [メール受信/OFF] 削除キー/
■7384 / inTopicNo.12)  Re[8]: SQL Server の IDENTITY について
□投稿者/ 尾形 -(2013/01/22(Tue) 16:16:42)
    >  &STR = " '" + \
          ",MAX( `ID` )" + \
          " FROM `mst_tokui`" + \
          " ; -- "

    ダミー.xvwで、任意の入力中のテーブル
    (上記サンプルは、mst_tokuiとしてます)
    から、[ID]のMAXを取得してきます


    > つまり[ID]を別のテーブルの[項目1]から生成する
    同一テーブルからMAX取ってきます

    http://tayu.o0o0.jp/bbs/kiri/cbbs.cgi?mode=al2&namber=5556&no=0&KLOG=36
    ここの#5586以降あたりが
    面白いですよ


引用返信 [メール受信/OFF] 削除キー/
■7383 / inTopicNo.13)  Re[7]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/22(Tue) 15:18:12)
    尾形さん、ありがとうございます。

    このイベント処理では、同時複数アクセスで、[ID]がコリジョンするリスクはないでしょうか?


    ダミー.xvwで[ID]が最大のレコードの[項目1]に1足した数を、
    最初の編集対照表の[ID]に入れるわけですね。

    つまり[ID]を別のテーブルの[項目1]から生成する、と。
    ここで得られる[項目1]にはどんな値がはいっているのでしょうか?
引用返信 [メール受信/OFF] 削除キー/
■7382 / inTopicNo.14)  Re[6]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/22(Tue) 14:57:10)
    うにんさん、ありがとうございます。

    > ODBCとかSQLサーバ側のログのことです。

    私の調べ方が悪いのかもしれませんが、
    どちらの場合もトリガの動きなどは見えませんでした。


    > 直接行追加するより、表に入れて読み込みしたほうが
    > 楽かなあという気が...
    > (読み込みだと再抽出があんまり気にならないので)

    桐表の便利な機能を捨てて、あえて外部DBを直接編集する根本的な理由は、
    ワーク表と外部DBの同期がきちんとなされないトラブルでした。

    また、明記しておりませんでしたが、行追加の他にも、行訂正と行削除もするため、
    ワーク表と外部DBを同期する際は、読み込みではなく、次の様に若干複雑になります。

    編集表 テスト外部DB
    併合 テスト桐表, 両方, { [ID]照合, [項目1]複写, [項目2]複写 }

    編集表 テスト桐表
    削除行 有効
    絞り込み [ID]{ #削除 }

    編集表 テスト外部DB
    併合 テスト桐表, 両方, { [ID]照合, [項目1]複写, [項目2]複写 }
引用返信 [メール受信/OFF] 削除キー/
■7381 / inTopicNo.15)  Re[6]: SQL Server の IDENTITY について
□投稿者/ 尾形 -(2013/01/22(Tue) 12:56:26)
    どうも、こんにちは
    シビアな状況でなければ、お手軽に


    手続き定義開始 フォーム::行挿入終了前(・・・・)
    条件    ( &モード <> 1 ) 手続き終了
    代入    &STR = " '" + \
              ",MAX( `ID` )" + \
              " FROM `mst_tokui`" + \
              " ; -- "
    代入    &秒 = #IS表
    手続き実行 Lib_編集表xvw( "ダミー.xvw" , "" , "" )
    再抽出   終了状態=&終了,変数使用=する
    代入    &件数 = #NVL( #数値( [項目1] ) , 0 )
    編集表   &秒
    項目値代入 [ID] = &件数 + 1
    手続き定義終了

引用返信 [メール受信/OFF] 削除キー/
■7378 / inTopicNo.16)  Re[5]: SQL Server の IDENTITY について
□投稿者/ うにん -(2013/01/21(Mon) 23:36:02)
    >>トレースログを見ました?
    >
    > ONとOFFの順序を変えても、そのままでも、トレースでは下記の様になりました
    >
    > エラー :KD1672:ODBC エラー データソース固有エラーコード : 544 SQLSTATE : 23000 [Microsoft][ODBC SQL Server Driver][SQL Server]IDENTITY_INSERT が OFF に設定されているときは、テーブル 'テスト表' の ID 列に明示的な値を挿入できません。 (C:\テスト表.xvw(外部DB) )

    ああ、すいません、桐の一括処理のトレースじゃなくて、ODBCとかSQLサーバ側のログのことです。

    postgresqlで使ってますけど、直接行追加するより、表に入れて読み込みしたほうが
    楽かなあという気が...
    (読み込みだと再抽出があんまり気にならないので)

引用返信 [メール受信/OFF] 削除キー/
■7377 / inTopicNo.17)  Re[8]: SQL Server の IDENTITY について
□投稿者/ 今村 誠 -(2013/01/21(Mon) 22:54:10)
    そらさんこんにちは、桐でも同じだと思いますが、カウンター項目に
    値を設定しようとすれば断られると思います。
     外部データベースには主キーがないと索引も作れないし、検索や
    絞り込むにも不便だと思います。
    私の提案した日付+ユーザー特定暗号は英字2文字ですが50000人くらい
    PCユーザーがいても#WSNAMEと2文字の大文字英字と小文字英字を使い
    ユーザー名一覧表から表引きして代入すれば簡単に実装可能です。
     行番号を何桁付加するのか書いてありませんが、1行の追加入力に
    0,1秒以上必要ではないでしょうか?
     日時値を変換した時点で、同一使用者での同じ日時値はあり得ません。
    並び替えも問題ないしユーザー名も判別可能な中で、行番号を付加する
    意味が全くわかりません。
     カウンター数値項目が何のために必要なのか解りません。
     主キーがイベントで作れるのだから必要のない項目は削除してはいかが
    でしょうか。

引用返信 [メール受信/OFF] 削除キー/
■7376 / inTopicNo.18)  Re[4]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/21(Mon) 18:12:29)
    うにんさん、ありがとうございます。

    ご指摘下さったとおりに、ONとOFFを入れ替えてみましたが、症状は全く同じでした。


    > トリガを実行する前にINSERT文をチェックするんですかね?

    おそらく仰る通りだと思います。


    > トレースログを見ました?

    ONとOFFの順序を変えても、そのままでも、トレースでは下記の様になりました

    エラー :KD1672:ODBC エラー データソース固有エラーコード : 544 SQLSTATE : 23000 [Microsoft][ODBC SQL Server Driver][SQL Server]IDENTITY_INSERT が OFF に設定されているときは、テーブル 'テスト表' の ID 列に明示的な値を挿入できません。 (C:\テスト表.xvw(外部DB) )
引用返信 [メール受信/OFF] 削除キー/
■7375 / inTopicNo.19)  Re[7]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/21(Mon) 18:03:13)
    尾形さん、ありがとうございます。

    そうですよね。
    やはりイベントが必要になってしまいますよね。

    ただ、障害発生時の原因究明や、手作業でのデータメンテナンスを想定すると、
    出来れば外部DBを直接手作業で編集できるようなシンプルさが保てる事が、
    望ましいとも感じております。
引用返信 [メール受信/OFF] 削除キー/
■7374 / inTopicNo.20)  Re[7]: SQL Server の IDENTITY について
□投稿者/ そら -(2013/01/21(Mon) 17:56:52)
    今村さん、ありがとうございます。

    15文字削減できるわけですね。
    速度が問題になる場合、どれだけ速度が改善できるか検証してみようと思います。


    > * 生成文字の末尾に使用者名の2文字のイニシャルを付加すれば簡単では

    #ユーザ名の一部を使用するという意味でしょうか?
    そうではなく、端末ごとにイニシャルを事前登録する仕様は、できれば避けたいと考えております。
    仮にそのような仕様にする場合には、日時値は一定日時(例.1980/1/1)からの経過秒数に変換し、
    イニシャルではなく2桁の整数を使うことで、[ID]を数値型にしようと考えております。


    また、先程の式では #WSNAME と #行番号 のサニタイジングが抜けていたため、修正しました。

    項目値代入 [ID] = #日時文字列( #日時値, 9, 4, 2 ) \
        + #条件選択( \
            #文字数( #WSNAME ) > 10 , #右側文字列( #WSNAME, 16 ), \
            1, #WSNAME ) \
        + #文字列( #MOD( #行番号, 100000000 ) )
引用返信 [メール受信/OFF] 削除キー/

次の20件>

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

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

- Child Tree -
- Antispam Version -