Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>Your strategy depend on your ability to identify uniquely ever row.</p> <p>If you <strong>can create a unique key</strong> to every row (not necessary that you have created a <code>UNIQUE</code> constrain), then:</p> <ol> <li>Copy all data to <code>Beta</code>. Do your changes by <strong>marking</strong> affected rows or creating <code>NEW</code>,<code>UPDATEd</code> and <code>DELETEd</code> tables. </li> <li>Copy marked rows only to <code>Production</code>.</li> <li><p>Apply changes. If you can find out that <code>Production</code> rows had been changed since your copy - decide ho to deal with it.</p> <p>Insert INTO Pro_Table SELECT * FROM New_Rows_Table</p> <p>UPDATE Prod_Table set Prod_Col_1 = Upd_tbl_c1, Prod_Col_2 = Upd_tbl_c2, ... , Prod_Col_N = Upd_tbl_cN from Update_Table where Prod_Table.RowKey = Update_Table.RowKey</p> <p>DELETE FROM Prod_Table FROM Delete_Table where Prod_Table.RowKey = Delete_Table.RowKey</p></li> </ol> <p>This is SQL Server code style, but you can get the idea and make necessary changes. For example Delete_Table should have RowKey column only.</p> <p>If you <strong>can NOT create a unique key</strong>. You have some options:</p> <p>Number all your rows by adding a new column and populating it with Row_Number() function.</p> <p>OR</p> <p>Lock your database for any changes or do not apply them and store separately. After your changes promoted to <code>Production</code>, apply deffered changes.</p> <p>OR</p> <p>Capture all <code>INSERT</code> , 'UPDATE' and <code>DELETE</code> statements on <code>Production</code> database using triggers. You need Inserts as they may be affected by later Updates and Deletes.</p> <p>When making changes on <code>Beta</code> copy rows you change manually on <code>Beta</code> into separate table(s).</p> <p>After your changes are done, review captured data from <code>Production</code> and decide how to apply them to rows you've changed and copied from <code>Beta</code>.</p> <p>To avioid problems with foreign keys, copy / import your updated table under a different name. Rename original table and then new one. Drop original table. This way you do not delete any data and all foreign keys are enforced all the time.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload