Activity overview
Latest activity by dbaRobRich
I used the SQL Compare tool to generate a script to move the comments in the extended properties from one environment into another. The SQL Compare tool correctly generated the script to move the information. There were some other differences between the two environments which were also included in the generated script.
Therefore I would like to see the SQL Compare tool enhanced to select only the comments. Until this enhancement is made, I can edit the generated script and discard the other changes I do not want to migrate at the same time.
Again, thank you for helping me find a solution to this problem. / comments
I used the SQL Compare tool to generate a script to move the comments in the extended properties from one environment into another. The SQL Compare tool correctly generated the script to move the ...
I haven't had time to try your suggestion. I will give it a try and post the results in a reply.
Thank you for your assistance. I appreciate you taking the time to understand our requirements. / comments
I haven't had time to try your suggestion. I will give it a try and post the results in a reply.
Thank you for your assistance. I appreciate you taking the time to understand our requirements.
We use scripts generated by the developers to deploy all changes. Stored procedures are externally stored as drop/create scripts in our source library. Changes to database objects such as tables or indexes are scripted either by writing the script or using Management Studio to generate the script via the interactive interface.
I attempted to write a script to pull extended properties from one server and update to another server. The complication arrises because Microsoft provided system stored procedures are used to maintain the extended properties. To use these procedures requires dynamic SQL statements be generated by reading the information from the system tables and generating execute stored procedure statements. This is managable with one or two tables, but not with hundreds of objects in a database.
Another alternative is to update the system tables directly without using the supplied system stored procedures. My experience as a DBA leads me to believe that updating internal system tables directly without using provided stored procedures is not a best practice.
This brings me to the conclusion that the best option is to code a program to migrate the data from a development server to a production server. I was hoping this type of program could be provided by a vendor such as Red Gate instead of developing a program in house. / comments
We use scripts generated by the developers to deploy all changes. Stored procedures are externally stored as drop/create scripts in our source library. Changes to database objects such as tables ...
A tool that would just move the extended properties would be an ideal solution. Maybe this could be a new feature of SQL Doc or SQL Compare.
I understand the benefits of storing the documentation information directly inro the subject database. However with our ever increasing seperation of production and nonproduction environments dictated by SOX auditors, it becomes very difficult, if not impossible, to grant the developers and designers any update permissions in the production databases.
Currently all updates are scripted and tested in nonproduction environments. Then the tested scripts are applied to the production envrionment by the production dba.
Thus we need an automated method of deploying this documentation information from the nonproduction environment to the production envrionment. / comments
A tool that would just move the extended properties would be an ideal solution. Maybe this could be a new feature of SQL Doc or SQL Compare.
I understand the benefits of storing the documentation ...
Extended Properties and Developer Update Access
In our environment, developers do not have any update permissions in our Production environments. One of our developers purchased SQL Doc to document our numerous databases. She has update permis...