I am not a 24/7 database admin. I am project manager / development lead here and I am also responsible for several mid sized production, test and development databases. What I am trying to say, is that I am not necessarily the top expert in database administration.
Because of this, and because I feel that VSTSDBP is actually aimed more at me / us than the 24/7 administrator I am concerned that this tool increases the danger of inadvertantly doing serious damage. This would be the case when a schema compare is run and one too quickly does an update.
Since it is normal (I hope / think so anyway) that each instance could have different users, roles, permissions and role memberships defined (I do that to prevent the developers from having direct access to production objects) I would expect that this tool would BY DEFAULT have the setting of all such objects in the schema compare set to "Skip". At the update command modal warning this setting could be shown (letting me abort and go back to change it if I really want these items). If I want to update these objects I should have to do so explicitly.
It wouldn't be the worse thing, if the modal dialog (already there when doing an update from schema compare) also showed the active deployment / update DB instance including servername. (It wouldn't be the first time we were in the wrong copy of the DB would it )
I would also expect the Filter for schema compare to not only filter the results pane but also the Update Skript. When I Filter for different objects and only see different objects then I would only want to update different objects. If I want to update / do more than I have to at least have them shown. This is normal behaviour in all programs (i.e. SQL / EXCEL / ACCESS / etc. - if you filter then you only change what is not filtered out).
Of course there is not excuse for not knowing what I am doing, but I think something similar has happened all to often to all of us. Especially when we are not 24/7 administrators.
If I'm way off, feel free to let me know. The question here is - can you still do something to help prevent inadvertant changes without it becoming a burden for the user I think so as outlined above.
Alle
This tool could be dangerous
Simone1
At this point this product makes it too easy to wipe out a production database. Imagine someone imports a db schema from a production database, he creates a dgp. While he is short on time he executes this dgp. Here are the steps he follows:
1) open dpg
2) click on run/generate data
3) select Target Database (the production database is listed in this drop down list, however, i seriously doubt, that anybody ever would like to select the production database here)
4) he answers the question" do you want to wipe out your db with yes
-> the drop down list in step 3 should only list databases which a user would like to select as a target database for dgp's.
Computer Guy69146
Michael Drüing
Thanks for your feedback.
With this tool we are targeting people who are developing, maintaining and deploying database schema's; we do not position it as an administration or operational management tool set especially since everything is based around source code manipulation, although some people like myself manage servers through code, instead of point and click, purely because I want to know what is being send to the server.
We do expect users apply the normal due diligence when deploying generated code; but if users happen to have the privileges to execute SQL statements any script can potentially harmful and when you do not take any precautions, you make yourself vulnerable.
Schema compare actually does show the source and target server and database information in the header status bar using the: server\instance.database.owner notation or when you compare against your project it shows the project name.
Also when you want to deploy the changes to the target we do ask you to explicitly confirm
---------------------------
Microsoft Visual Studio
---------------------------
Are you sure that you want to update the target
---------------------------
Yes No
---------------------------
I know it is easy to say Yes, and we can make No the default button.
But please log your concerns on http://connect.microsoft.com so other users can vote as well and we will take this as input for future developments.
-GertD
“DataDude” Development Manager
jaimlin
What can I say; tools do not make the need for any process and proper access rights management obsolete.
I wrote Query Analyzer, if I go to the Object Browser and hit delete on the database node, and you say OK, bye bye database, same is true in Enterprise Manager, SSMS, TOAD for SQL Server etc etc.
VSDBPro is a development tool, which is why choose our build output to be a .SQL file so you can:
1. Examine it and see exactly what we will change in your database
2. Deploy this using any tool that understands .SQL file
3. And when you deploy it to production use a different security context then your own to prevent problems like described in this thread. It is a good common practices to NOT have direct access to your production server with high elevated rights like sysadmin etc. Same as in Unix where you never work as root, but use su to elevate your privileges when you need it and when you made a conscious decision that is what you want.
-GertD