問題タブ [rowversion]

テーブルに rowversion 列があり、その行を更新すると、rowversion 列の値が増加します。これは仕様によるものであり、rowversion 列の目的であることはわかっていますが、更新操作が rowversion 値に影響を与えないようにする方法はありますか?

編集: すべての列の更新を追跡する必要がありますが、新しいバージョンとして認識されないようにしたい操作がいくつかあります。

Entity Framework を使用しており、同時実行に使用するテーブルに rowversion (タイムスタンプ) フィールドがあります。ただし、エンティティ オブジェクトを更新するときに、rowversion 列を null に設定しようとし続け、エラーが発生します。

「LmpDemoRequest」の「VerCol」プロパティを「null」値に設定できませんでした。このプロパティを 'Byte[]' 型の null 以外の値に設定する必要があります。

エンティティ定義内に VerCol 列がありますが、"Setter" 関数を削除できません。

エンティティ フレームワークがこの列を設定しようとするのをやめるにはどうすればよいですか?

MySQL の組み込みの行バージョン管理メカニズムはありますか? MS SqlServer の「タイムスタンプ」列に似たもの。

Microsoft.SqlServer.Management.Smo.SqlDataType列挙型にはタイプの値がありますが、ではありtimestampませんrowversion。アセンブリの更新バージョンまたはそれをサポートする代替列挙型を探しています。

既存の列挙型にはの値がありますが、ドキュメントにTimestampよると、「非推奨であり、将来のバージョンで削除される予定です」。非推奨のものの使用は避けたいです:)rowversiontimestamp

SQL Serverにテーブルがあり、テーブルの最後に挿入を追加します（中央に挿入されるクラスタリングキーとは対照的です）。これは、テーブルが常に増加する列によってクラスター化されることを意味します。

datetimeこれは、列でクラスタリングすることで実現できます。

しかし、私は2つThingsが同じ時間を持たないことを保証することはできません。したがって、私の要件は、日時列では実際には達成できません。

ダミーのID int列を追加し、その上にクラスター化することができます。

しかし、私のテーブルにはすでに列が含まれていることに気付くでしょうtimestamp。単調に増加することが保証されている列。これはまさに、候補クラスターキーに必要な特性です。

したがって、テーブルをrowversion（aka timestamp）列にクラスター化します。

順序を確認するためにダミーのID 列（RowID）を追加するのではなく、intすでに持っているものを使用します。

私が探しているのは、なぜこれが悪い考えなのかという考えです。そして他にどんなアイデアが良いのか。

注：回答は主観的なものであるため、コミュニティwiki。

私は、1 つの DB ですべての変更を取得し、それらを別の DB に同期するシンクロナイザー ソフトウェアを作成しています。Tこの目的のために、テーブルに2 つの列を追加しました。

これで、最後の同期以降に変更されたすべての行を簡単に選択できます。

ただし、同期を実行した後、2 つのフィールドを等しくする必要があります。ただし、行を更新するとタイムスタンプも更新されるため、次のようにする必要があります。

しかし、私は疑問に思っています-これは常に機能しますか? の値を読み取った@@DBTS後、自分の行がコミットされる前に別のユーザーがどこかで行を挿入/更新した場合はどうなりますか? これは危険なコードですか？はいの場合、どうすれば改善できますか？

RowVersion列の値自体は、行が更新されるたびに変化することを除いて、それ自体では役に立たないことを知っています。しかし、相対的な（不等式）比較に役立つかどうか疑問に思っていました。

列を持つテーブルがある場合RowVersion、次のいずれかに該当します。

• 同時に発生するすべての更新 (同じ更新ステートメントまたは同じトランザクション) は、RowVersion列に同じ値を持ちますか?
• 「A」を更新してから「B」を更新すると、更新「B」に含まれる行の値は、更新「A」に含まれる行よりも高くなりますか?

ありがとう。

SQL Server 2005 Enterprise SP3を実行しており、SQLServer2005モードで実行されている新しいデータベースで行バージョン管理を有効にしようとしています。

クエリ（マスターデータベースに対して）：

結果：

何か案は？masterデータベースとpod-moodleデータベースをトリプルチェックしました。どちらも2005モードで実行されています。

新しい中間層にはLINQtoSQLとWCFを使用しており、実際のLINQクラスを使用するのではなく、データ転送オブジェクトを使用してネットワークを通過させています。更新が正しく機能し、同時実行が正しく処理されるようにするために、ここで概説するメソッドのいずれか（タイムスタンプまたは行バージョンに基づくLinq Table Attach（））を使用します。

読み取り時間を節約するために、基本的には、テーブルでタイムスタンプ/行バージョン列を使用するか、デフォルトと更新トリガーを備えた日時列を使用できます。どちらの方法でも、毎回新しく生成された値を取得する列を取得できます。挿入または更新が発生し、その列はLINQが同時実行性をチェックするために使用する列です。

私の質問は-どちらが良いですか？多くのテーブルに「UpdatedWhen」の日時列がすでにありますが（すべてではありません-質問しないでください）、デフォルトとトリガーを追加するか、rowversionを追加するだけです（使用する必要があります）今のところ、タイムスタンプの構文は、各テーブルに対してSQL2005をしばらくサポートしているため、どちらの方法でも、DBを機能させるために変更しているので、パフォーマンスに違いがあるかどうかを知りたいです。これら2つの選択肢の間に注意すべき他の重要な違い。私はウェブとここSOで検索しようとしましたが、今のところ運がありません。ありがとう。

SQL Compact 4.0 とエンティティ フレームワーク 4 を使用する単純なコンソール アプリがあります。データベースには、 (StoreGeneratedPattern: Identity, Type: Int32)、(Type: string)、(StoreGeneratedPattern: Computed, ConcurrencyMode:)Section の 3 つの列を持つ単一のテーブルがあります。固定、タイプ: バイナリ、MaxLength: 8)。TimeStamp 列は、実際には SQL Compact の rowversion 型です。Id Title TimeStamp

メインに次のコードがあります。

最初の SaveChanges() メソッドの後で TimeStamp 列がデータベースから更新されないため、このコードは同時実行例外をスローします。SQLServer2008 では問題なく動作することに注意してください。

これはコンパクトのバグですか、それとも何か不足していますか?

ありがとう、

ダレン