Firstly, many thanks from the SQL Response team at Red Gate to all our beta testers. You’ve given us invaluable feedback over the last couple of months since SQL Response beta was released. I don’t think we quite anticipated the volume of quality feedback we’ve gotten, and it’s taken some time to really get to grips with it all!
We have been carefully considering your comments and ideas as we evaluate how the final version of SQL Response should behave and feel. As a result of our beta testers’ feedback and our own testing at Red Gate, we’ve realised there are some things we definitely need to do to make the product really excel at what it does. Three key areas we’re going to be looking at carefully are configuration and prioritisation of incidents; quantity of information; and navigation.
To touch on these in a little more detail: you’ve got across to us that even though it’s great SQL Response “just works†out of the box, reasonable detailed configuration is still a required feature in order to avoid false positives and information overload. You really want to be able to prioritise incidents with reasonable granularity to differentiate between critical and non-critical incidents. We need to do some work on the amount of information (particularly the number of incidents) which is presented up front, again to cope with information overload. But we need to make sure this doesn’t impede your ability to quickly and easily navigate to the detailed information you want to see.
Part of this work also includes making some of SQL Response’s really key features much easier to access. Our performance information and SQL trace are examples of this. It needs to be clearer what SQL Response does in these areas, rather than you having to play “hunt the featureâ€.
Naturally this work will take some time to get right, and we regret that this means the full version release of a tool that’s keenly anticipated by many of you is set to be another three to four months away. Our aim behind the wait, though, is to do our best to make sure the tool is one you could really use in the long term, and which meets the standards of quality and performance that you (and we) expect.
We’ll keep you posted on the development of SQL Response as we go, and we would very much appreciate your continued feedback during this time.
We have been carefully considering your comments and ideas as we evaluate how the final version of SQL Response should behave and feel. As a result of our beta testers’ feedback and our own testing at Red Gate, we’ve realised there are some things we definitely need to do to make the product really excel at what it does. Three key areas we’re going to be looking at carefully are configuration and prioritisation of incidents; quantity of information; and navigation.
To touch on these in a little more detail: you’ve got across to us that even though it’s great SQL Response “just works†out of the box, reasonable detailed configuration is still a required feature in order to avoid false positives and information overload. You really want to be able to prioritise incidents with reasonable granularity to differentiate between critical and non-critical incidents. We need to do some work on the amount of information (particularly the number of incidents) which is presented up front, again to cope with information overload. But we need to make sure this doesn’t impede your ability to quickly and easily navigate to the detailed information you want to see.
Part of this work also includes making some of SQL Response’s really key features much easier to access. Our performance information and SQL trace are examples of this. It needs to be clearer what SQL Response does in these areas, rather than you having to play “hunt the featureâ€.
Naturally this work will take some time to get right, and we regret that this means the full version release of a tool that’s keenly anticipated by many of you is set to be another three to four months away. Our aim behind the wait, though, is to do our best to make sure the tool is one you could really use in the long term, and which meets the standards of quality and performance that you (and we) expect.
We’ll keep you posted on the development of SQL Response as we go, and we would very much appreciate your continued feedback during this time.