- PR -

Oracle：TimeStampと.NET：DateTimeの比較について

«前のページへ 1|2
投稿者投稿内容
かるあ
ぬし
会議室デビュー日: 2003/11/16
投稿数: 1190
お住まい・勤務地: センガワ→ムサシノ
投稿日時: 2007-10-29 10:20
引用:

ひろさんの書き込み (2007-10-29 09:47) より:

読み込んできたデータセット内で、ミリ秒の精度があるようですので、
更新 SQL の WHERE 句で、テーブルの TIMESTAMP の値を文字列変換して比較
すればいいのでは？

列側に関数を使ってしまうとちょっと嫌な感じ、まだ試してないんですが Anthyhime さんの示された OracleDataAdapterの安全な型マッピング をうまく使えばできそうな気がします。

引用:

ただ、これでも精度的に一致してしまう行が複数あるとだめですね。

＃当主さんの立場や環境がわからないので何とも言えませんが、更新のキーに日付関連
項目を使用するのはあまり好ましくないと思われます。
やはり、そのテーブルのプライマリーキーで更新するのがいいのかな、と。
プライマリキーが無ければシーケンスでも用意して作成するのがよさげ。
もちろん、「プライマリーキーが存在しない」とか、「テーブルの仕様は変更不可」
など制約があるのかもしれませんが、その辺りの事は私たちには判らないです。

プライマリキー＋日付で楽観的同時実行制御を実現するのは結構常套手段じゃないですか？
_________________
かるあ のメモ と スニペット
ひろ
会議室デビュー日: 2007/09/19
投稿数: 9
投稿日時: 2007-10-29 13:40
実現方法については、簡単に実現出来そうだと思ったので書きましたが、
このへんはお好みで。
（これで実現できないというのであればまずいですね。）

あと、同時実行制御（排他？）ですが、スレ主さんの最初の書き込みを読んで、

「プライマリキー＋日付」での更新行の特定

ではなく

「日付」のみで更新行の特定

という風に読めたのでこう書きました。

＃プライマリキーがあるのであれば「日付」を入れる必要はないんじゃ…
ひろ
会議室デビュー日: 2007/09/19
投稿数: 9
投稿日時: 2007-10-29 13:55
今、気が付いたのですが、「排他」したかったんですね。
であれば、私のはだめですね。

失礼しました。
RUN
常連さん
会議室デビュー日: 2007/10/05
投稿数: 32
お住まい・勤務地: 東京都
投稿日時: 2007-10-30 01:34
引用:

当主さんの書き込み (2007-10-26 17:42) より:

安全なマッピングの言いたいことはわかりますが、その実装方法が理解できませんでしたし、
OracleDateTimeに関しては、結局その型で取得してもDataTableに設定する際には
DateTimeにしなくてはいけないので意味が無いように思います。


何故意味が無いと思うの？
deannaさんが提示しているTO_CHAR使用の方法についても意味がないと思うと言って拒否してるよね？

正直意味が無いと思う理由がわからない。

まず、TimeStampとDateTimeの比較の目的って、排他制御なんだよね？
んで、日付型を排他制御に使いたいって事は、更新時間系のカラムが比較したいカラムな訳だよね？
んで、データ取得時の更新時間とUPDATE時の更新時間が違っている場合、他のアクセスによりデータが変更されているから排他エラーにしたいと言う事だよね？

この前提が間違っているなら、これから自分が言う事は全て的外れな話になるけど。
排他比較の為に保持してある更新時間って、排他比較にしか使わないよね？
実際の更新に際しては更新時間を現在時刻に更新しないとそもそもこの方法での排他制御は成り立たない訳だからこの時点で、排他比較用に取得して置いた時間と言うのは更新時間カラムへと挿入できる形である必要は無いよね？
であれば、最初に排他制御用に日付を取得する場合、それをdeannaさん提示の文字列として取得してもどこにも問題はない訳だ。

んでだ、更新するときにTimeStampと最初に取得した文字列を比較する訳だけど、そのままでは比較が出来ないが、別にそのまま比較する必要も無いよね。
文字列の方をTimeStamp型へ変換するか、更新時間カラムを文字列に変換すれば比較は出来る訳だから。

取得時が
SELECT TO_CHAR(xx,'YYYYMMDDHH24MISSFF3') FROM ...
と言う感じなら、排他チェック時のWHERE句を
WHERE TO_CHAR(xx,'YYYYMMDDHH24MISSFF3') = @pa_ShutokuTime
(@pa_ShutokuTimeは最初のSELECT時に取得したTO_CHAR(xx,'YYYYMMDDHH24MISSFF3')の値)
とすれば、排他チェック時の比較は成立するよね？

十分、意味のある手法だと思うのだけど

TimeStamp型に固執して、他の型を利用する方法を意味がないように思うと拒絶しては、何も進まないと思いますよ
けい
会議室デビュー日: 2006/08/09
投稿数: 5
投稿日時: 2007-11-01 14:46
引用:

deannaさんの書き込み (2007-10-26 16:46) より:
OracleのTimeStampを文字列にして扱えばいいのでは。
SELECT TO_CHAR(xx,'YYYYMMDDHH24MISSFF3') FROM ...
とか

引用:

当主さんの書き込み (2007-10-26 17:00) より:

deanna様

アドバイスありがとうございます。
取得時にはミリ秒も取れていますし、データテーブルに設定する際には
DateTime型のものを設定しないといけないので解決にはならない気がします。
TimeStampにはSYSTIMESTAMPで自動設定したいと考えてもおりますし。


SELECTした主キーと更新日時が
UPDATEする時に同じ場合にSYSTIMESTAMPを更新日時にセットするのでしょう？
SELECTした更新日時はUPDATEに使わないわけだからdeannaさんの方法でOKだと思いますよ。
かるあ
ぬし
会議室デビュー日: 2003/11/16
投稿数: 1190
お住まい・勤務地: センガワ→ムサシノ
投稿日時: 2007-11-01 15:21
安全な型マッピング をするための SafeMapping メソッドは ODP.NET にしかないんですね。
しかも内部的には文字列で処理をするようだし、TO_CHAR して持ってくるのがいいようですね。

＃次のバージョンでは TableAdapter に対応するという話もありますが、まだ Beta だしね
_________________
かるあ のメモ と スニペット
当主
会議室デビュー日: 2006/12/10
投稿数: 16
投稿日時: 2007-11-08 18:17
皆様

大変遅くなってしまいましたが、結果報告をしたいと思います。
結論から言えば、DBの型自体を変更してVARCHAR2にしてしまいました。
それによって取得・比較はそのまま扱い、設定・更新に関しては
SYSTIMESTAMPをTO_CHARすることで解決しました。

TIMESTAMP型とDataTableのあたりで勘違いがあり、それが原因で
型変換をしないような方法を模索していた次第です。

今回、アドバイスをいただいた方々に感謝をしつつ、このスレッドを
終了しようと思います。
ありがとうございました。
«前のページへ 1|2

スキルアップ／キャリアアップ（JOB@IT）