How can we help you today? How can we help you today?

Split Table: "Copy" vs. "Move"

I just tried to split HumanResources.Employee in AW, and copied BirthDate, Gender, and HireDate over to a new table -- but did not move anything. Yet, SQL Refactor wants to drop some triggers, modify some views, etc, etc. Why is any of that necessary? If the columns are only being copied, shouldn't it just create a new table and stop there?
amachanic
0

Comments

3 comments

  • Andras B
    amachanic wrote:
    I just tried to split HumanResources.Employee in AW, and copied BirthDate, Gender, and HireDate over to a new table -- but did not move anything. Yet, SQL Refactor wants to drop some triggers, modify some views, etc, etc. Why is any of that necessary? If the columns are only being copied, shouldn't it just create a new table and stop there?

    It should not drop triggers, and that will be fixed. Rewriting views on the other hand is a bit more tricky. If one wants to add columns to the primary table and turn the relation between the two (and make it an 1:n), the join is important. We were thinking about adding an option/not applying joins for splits where a set of colums is only copied. This would certainly be helpful for cases when one creates the secondary table to enforce domain restrictions via referential integrity.

    Regards,
    Andras
    Andras B
    0
  • amachanic
    What if I don't want to enforce anything at all? Perhaps I just want to use the tool to help me quickly copy some data into a new table?
    amachanic
    0
  • Andras B
    amachanic wrote:
    What if I don't want to enforce anything at all? Perhaps I just want to use the tool to help me quickly copy some data into a new table?

    That is sort of a different use. But if one wants only a select statement that selects a few columns from a table, and copies them over to a newly created table, one can of course copy the relevant part of the generated script. To identify what the relevant part is will be assisted by a separate feature in the oncoming beta. While many of the table split features we can set automatically, it is always recommended to go through the generated script. (one reason for not executing the script automatically). The generated scrip on the other hand gives you a very good starting point, with ordered alter statements for the dependent objects.

    Andras
    Andras B
    0

Add comment

Please sign in to leave a comment.