プライマリキーが既定のNewIDのGUIDであるテーブルがあります。私がそれをバックアップしたときにPKカラムの値がXYZだった場合、私は復元されたテーブルのXYZを期待します。実際に私はPQRを取得します（GUIDに相当）。復元時にGUIDが再生成されるようです。これは実際に起こっていますか（それは少し狂っているようです）、もしそうなら、どのように回避することができますか？SQL Server：リストア時にGUID再生成を回避するには？
復元時にあなたのデータが変更される人は誰もいません（私はあなたがバックアップ/リストアを真のBACKUP/RESTOREステートメントとみなし、カスタムデータコピーソリューションではないと思います）。 guidが変更された場合は、別のデータを復元したか、自分でデータを変更していて、いつ（アプリケーションを起動するのか）正確には分かりません。
1のコピーを投稿してください - あなたの場合、デフォルトではONLYでキック新しい行を挿入し、特定の列の値を調べないでください。これは復元時には発生しません。 –
私がテストで見つけたものは次のとおりです：WITH REPLACEオプションを使用していました。ログの末尾をバックアップしていませんでした。これは、私がGUIDSを再生成して記述した問題を引き起こすように見えます。面白いことに、ログをバックアップしてWITH REPLACEを使用すると、すべてがOKです。このシナリオではb/c WITH REPLACEが無視されているのか、何か他のものがアップしている場合はわかりません。 –
だから、基本的にあなたは*異なる*データを復元しています。 GUIDが「問題」になっていないのは、あなたの*全体の*データベースで、単にRESTOREの後に別のものを見るだけです。 –
には、これはちょうど私もあなたの代わりにNEWID（）のNEWSEQUENTIALID()を使用するには、uniqueidentifier列にPKを持っている場合NEWIDを（）に恐ろしいpagesplitsの原因になりますので、ことを指摘したい
を復元で発生することはできませんクラスタ化インデックス（主キーは、デフォルトである）
私はここでの違いを示すいくつかのコードを持っている：Some Simple Code To Show The Difference Between Newid And Newsequentialid
正確にあなたのテーブルのDDL – Aheho