• Replies 5 replies
  • Subscribers 338 subscribers
  • Views 149 views
  • Users 0 members are here
Related

LIVE to TEST Overwrites

Matt Gonzales
$organization

Forgive me if I've asked this question before or if it's well-trod ground by this point, but what is the recommendation for a common scenario (for us, at least) wherein a contractor works with us to develop custom screens in our TEST database but ends up losing their work when a LIVE to TEST copy happens. Surely there's a way to keep that information saved that doesn't involve simply re-entering it by hand - especially since the contractor may charge additional money for the time it takes for them to put that code back. During rollover, we typically do LIVE to TEST copies every other day until it's all worked out. I know this may not be very efficient, but I'm working on that one, believe me.

Anyway, I hope someone can point me in the right direction, even if it's just giving me a proper keyword search for the issue.

Thanks in advance, Tessiturians.

Parents
  • $organization

    Hi Matt,

    Here are some things we do to help manage work like you are describing:

    • Similar to what Nancy described, we have additional Tessitura test environments used for various purposes, including development. We do this so that we can support a project that requires a stable environment over a period of time.
    • I try to get those involved in developing a solution (including me) to track what they are doing so we can find a way to deploy those changes as quickly as possible.
    • I use database schema and data comparison tools to try and identify differences between one of our test environments and live. The best tools I have found for this are Red Gate SQL Compare (for schema comparisons) and SQL Data Compare (for data comparisons). Those tools can create deployment scripts based on the differences, which can be useful. Visual Studio also has tools for this built-in (It may require data tools to be installed). You can find these in Tools - SQL Server - New Data Comparison and New Schema Comparison. They aren't as robust as the Red Gate tools, but are free.

    For a data comparison tool, you'd want to select tables to compare. For example, if the work involved adding or modifying system tables, you could focus attention on the TR_, LTR_, etc type of tables.

    A key thing, in my opinion, is having an environment that you can keep relatively stable for the duration of a project so it isn't impacted by scheduled or routine Live to Test copies. But if that isn't feasible, some of those tools could still be used to help identify the changes before a LIVE to TEST refresh is done. I hope this helps.

Reply
  • $organization

    Hi Matt,

    Here are some things we do to help manage work like you are describing:

    • Similar to what Nancy described, we have additional Tessitura test environments used for various purposes, including development. We do this so that we can support a project that requires a stable environment over a period of time.
    • I try to get those involved in developing a solution (including me) to track what they are doing so we can find a way to deploy those changes as quickly as possible.
    • I use database schema and data comparison tools to try and identify differences between one of our test environments and live. The best tools I have found for this are Red Gate SQL Compare (for schema comparisons) and SQL Data Compare (for data comparisons). Those tools can create deployment scripts based on the differences, which can be useful. Visual Studio also has tools for this built-in (It may require data tools to be installed). You can find these in Tools - SQL Server - New Data Comparison and New Schema Comparison. They aren't as robust as the Red Gate tools, but are free.

    For a data comparison tool, you'd want to select tables to compare. For example, if the work involved adding or modifying system tables, you could focus attention on the TR_, LTR_, etc type of tables.

    A key thing, in my opinion, is having an environment that you can keep relatively stable for the duration of a project so it isn't impacted by scheduled or routine Live to Test copies. But if that isn't feasible, some of those tools could still be used to help identify the changes before a LIVE to TEST refresh is done. I hope this helps.

Children
No Data