How can I track changes to a development database and apply those changes to a production database (SQL Server 2008)?
I keep a local copy of a database on my development server, and as I'm adding new features, I may add new tables or change field and table names in the database. What's a good way to track such changes and then apply them to the main database?
Is there some way to do a "diff"-like operation between two databases and merge definition changes?
I considered merge-replication, but I'm not sure how well than handles schema changes. For example, here: http://technet.microsoft.com/en-us/library/ms151870.aspx it mentions that I basically cannot use SSMS to make definition changes, because it drops and recreates tables, which is not allowed for published objects.
A smart piece of software could compare column counts, types, positions, and apply other fuzzy matching/logical deduction methods to figure out that a table was renamed or a new table was added or a column name changed, after which it could present the differences to the user for confirmation and automatic application.
Does anything like what I've described above exist, or am I stuck remembering to save DDL statements in SSMS and running them manually in the production database?
Maybe you need a migration tool like (for example) FluentMigrator, which helps you track database changes in source code.
Here is a tutorial from the original author of Fluent Migrator, explaining what Fluent Migrator is, why you might need it and how it works.
Another alternative would be what you already mentioned:
A smart piece of software could compare column counts, types,
positions, and apply other fuzzy matching/logical deduction methods to
figure out that a table was renamed or a new table was added or a
column name changed, after which it could present the differences to
the user for confirmation and automatic application.
I never tried it myself, but I've seen lots of recommendations for Redgate SQL Compare (which apparently does exactly what you asked for) here at Stack Overflow.
Related
I'm kinda new to this kind of problem. I'm developing a web-app and changing DB design trying to improve it and add new tables.
well since we had not published the app since some days ago,
what I would do was to dump all the tables in server and import my local version but now we've passed the version 1 and users are starting to use it.
so I can't dump the server, but I still would need to update design of server DB when I want to publish a new version. What are the best practices here?
I like to know how I can manage differences between local and server in mysql?
I need to preserve data in server and just change the design, data on local DB are only for test.
Before this all my other apps were small and I would change a single table or column but I can't keep track of all changes now, since I might revert many of them later and managing all team members on this is impossible.
Assuming you are not using a framework that provides a migration tool for database, you need to keep track of the changes manually.
Create a folder sql_upgrades (or whatever name you name) in your code repository
Whenever a team member updates the SQL schema, he creates a file in this folder with the corresponding ALTER statements, and possibly UPDATE, CREATE TABLE etc. So basically the file contains all the statements used to update the dev database.
Name the files so that it's easy to manage, and that statements for the same feature are grouped together. I suggest something like YYYYMMDD-description.sql, e.g. 20150825-queries-for-feature-foobar.sql
When you push to production, execute the files to upgrade you SQL schema in production. Only execute the files that have been created since your last deployment, and execute them in the order they have been created.
Should you need to rollback a file, check the queries it contains, and write queries to undo what was done (drop added columns, re-create dropped columns, etc.). Note that this is "non-trivial", as many changes cannot be rolled back fully (e.g. you can recreate a dropped column, but you will have lost the data inside).
Many web frameworks (such as Ruby of Rails) have tools that will do exactly that process for you. They usually work together with the ORM provided by the framework. Keeping track of the changes manually in SQL works just as well.
I'm working with a project which is using mysql as the database. The application is hosted with many clients and we are doing upgrades for the current live systems often.
There are some instances where the client has change the database structure(adding new tables) and causes some unexpected db crashes.
I need to log all the structural changes which were done at that database, so we can find the correct root cause for that. We can't do it 100% correct with diff tool because it will not show the intermediate changes.
I found http://www.liquibase.org/ tool but seems little bit complex.
Is there any well known technique or a tool to track database structural changes only.
well from mysql studio you can generate all object's schema definition and compare them with your standard schema definition and this way you can compare two database schema...
generate scrips of both database (One is client's Database and One is master copy database) and then compare it using file compare tool would be the best practice according to me because this way you can track which collumn was added, which column was deleted, which index was added like wise without any tool download.
Possiable duplication of Compare two MySQL databases ?
Hope this helps.
If you have an application for your clients to manage these schema changes, you can use a mechanism at application level. If you have a Python and Django-based solution, you could probably use South which provides schema change tracking and rollbacks.
I recently inherited a website and they have a simple back-end area which was created using phpmaker. The back-end displays various MYSQL database tables.
There are two tables which hold registration information related to promotions/contests the company runs online. The client wants to begin archiving the registration data monthly, but still have the data accessible for future export or review.
So, can anyone tell me what the best approach would be to achieve this? I read about partitioning and Maatkit, but I'm not sure which - if either - would be a smart choice.
I would prefer to keep the table names the same because the table name is referenced in several instances within the PHP code running the promo/contest applications. I would also like for everything to be 'automatic' or at least executed at the click of a button; though I realize that might not be completely realistic.
I should note that I do not have the phpmaker project file and have been unable to obtain it.
Any help on this matter would be a great help.
MK-Archiver This is a good way to archive live mysql database tables
What MK- Archiver does is to archive rows from a table to another table and/or a file
I have an Access 2003 database using MS-JET linked tables (that is, there are two *.mdb files). The overall task is to move to SQL server. However the existing databases have multiple fields with spaces and other characters that upset both of the Access migration wizards. So the intermediate task is to make a version of the existing mdb's with updated field names.
"Simply" changing field names in the UI mdb file doesn't work, because of the linked tables being read-only in that mdb. Updating the Data mdb file field names first doesn't work because the UI mdb then throws a wobbly on startup and Access gives up.
I'm looking for suggestions, but options I can see are:
re-integrate the Data mdb back into the UI one, do the updates, then re-export the data. Seems very risky to me (system is live, don't want to play with data any more than strictly necessary).
I've looked at several answers here relating to changing ODBC details with VBA code, which is interesting, and I can see how I might be able to programmatically edit the linked tables' names. Is this going to work? Is there a better way?
Unlink all linked tables, then edit in UI mdb the remaining forms, reports, queries (but would that work??) and edit the Data mdb fields, and finally relink everything. Will it fall apart?? ... seems likely.
Any suggestions?
Ruth
I go through this process every time I take over an existing Access application -- I have to bring it up to my own standards for naming conventions before I do anything significant with it. Recently I built a quick-and-dirty utility to rename fields. It was made for me and has very little error recovery, and a UI that is ugly, but it might be faster than doing it yourself.
See what track name autocorrect offers. How Name AutoCorrect Works in Microsoft Access
Make a copy of your UI MDB, delete the linked tables, then import them (as tables rather than links) from the Data MDB. Once you enable autocorrect, Access will attempt to propagate your field name changes wherever they are used (in forms for example). Unlikely it will catch 100% of the necessary changes, but it should resolve a big chunk of them. You would then need to manually track down and fix the rest.
Once you have everything fixed, you could use that MDB version to "upsize" your tables to SQL Server. However, one huge complication is if the original database is "live" while you're making changes to the new version. If you absolutely can't take the database out of service in the interim, you could discard the data from the new tables, then use "append" queries which alias the old to new field names to pull in the latest data.
INSERT INTO NewTable (emp_id, another_field)
SELECT
[emp ID],
[another field]
FROM OldTable IN 'C:\somefolder\Data.mdb';
Finally, a warning about autocorrect: do not leave it enabled in the production version of your database because strange things can happen. The safest approach IMO is to turn it on, complete your object name changes, then turn it back off again.
You might find Rick Fisher's Find and Replace tool helpful if you need to propagate name changes through the project. I've relied on it for years (though I don't do much Access development lately): http://www.rickworld.com/products.html
I think this tool will change the names of tables and fields for you but I am not sure. I mostly used it for finding references to tables and queries in other queries, form and report properties, and VBA code.
I have a small amount of experience using SVN on my development projects, and I have just as little experience with relational databases. I know the basic concepts like tables, and SQL statements, but I'm far from being an expert.
What I'd like to know is if there are any generic version control type systems like SVN, but that work with a database rather than files. I would like the same kind of features you get with SVN like the ability to create branches, create tags, and merge branches together. Rather than a revision number being associated to a version of a file repository it would be associated with a version of the database.
Are their any generic solutions available that can add this kind of functionality independent of the actual database schema? I'd be interested in solutions that work with MySQL or MS SQL Server.
I should also clarify that I'm trying to version control the data not the schema. I would expect the schema to remain constant. So really it seems like I want a way to create a log of all the INSERT, UPDATE, and DELETE requests sent the the database between each version of the data. That way any version could be recreated by resending all the SQL statements that have been saved up to the desired version.
You can script all your DDL, stored procedures and such to regular text files.
Then you can simply use SVN for database versioning.
I've never found a solution that works as well as Subversion, but here's a few things I've done that have helped:
Make scripts that will create the schema and populate any initial data. Then make an update script for each change after that. It's a fairly manual process, but it works. There's extra things that help like storing the current version number in a table in the db and making sure that the scripts are idempotent.
Store the full development db in Subversion. This doesn't usually work out too well for me if there is a lot of data or it is frequently changed. But in some projects is could work.
I keep and maintain create scripts in my version control system.
There are two things I can think of:
http://www.liquibase.org/ - provides a way of generally managing database changes. Creates files that get committed into source control, and it helps manage changes across different development databases, etc.
http://www.viget.com/extend/backup-your-database-in-git/ - this describes a strategy for backing up a database into source control, but the same strategy can be used just on the schema. In this scheme, the database would be in a separate area from your main code. (This can be used with other source control systems too.)