I have tools for propagating database definition changes, but any data changes I make I write scripts for and run them in each environment by hand.
There are some data changes/additions that have to be made routinely and I would like to create a GUI for handling this, but if I did that then I no longer have the sql scripts to run in other environments (unless I generate them from the GUI tool, but then I'm still left having to run those changes by hand in other environments).
One idea I'm mulling over is to write the GUI tool in such a way that it generates the xml files for objects I've added or changed and include these xml files in the publication of the web project. Then the application can look at these xml files and update the database accordingly.
Are there any standard practices or tools for pushing data changes automatically along with your db definition and/or code changes?
Based off the first answer I received it appears like I might have made it sound as though I want a tool to compare dev databases to production databases and propagate all changes. This is DEFINITELY NOT what I was trying to communicate.
One example of what I'm dealing with is language texts that have to be added (no, I can't use resource files for this because end users can modify the texts through the application at runtime). Instead of having to hand write scripts every time I need to add texts for a new item, it would be great if I could just create a GUI tool to simplify the process.
I think it's pretty obvious why I would prefer to use a GUI over hand writing SQL statements, and so the next question is why would I want to propagate this the same way we propagate code changes. Well, this isn't like other test data. This is data that will ALWAYS be propagated to each environment. The same sort of concerns that lead us to use tools to simplify the process of pushing code or database changes to each environment apply to the kind of data I'm talking about here.