You can try and use .Net Migrator to ease your work, but I'm afraid I haven't seen a fully automated solution, probably because of all the reasons Oskar mentioned: http://code.google.com/p/migratordotnet/
Whatever solution you choose, make sure you start using it fast and put someone in-charge of CM - working backwards is a pain... On Oct 9, 3:43 pm, Oskar Berggren <[email protected]> wrote: > While an automatic tool can find the differences between two schema > versions, and modify one of them to look like the other, this does not > say anything about the data in the existing database or the semantics > of it. I doubt that any automatic tool can ever, in the general case, > figure out the semantic changes and convert existing data. (E.g. a > customer table has address columns, in next version you introduce an > address table with a foreign key back to customer, now a script needs > to create the new table, extract address data from customers into new > table, referencing correct customer id, and only then perform the > schema change of removing the old address columns. And that was a > fairly easy case...) > > We write a number of "SQL patch scripts" that are each assigned a > sequential number. These are stored in version control of course, and > "compiled" as embedded resources. When a new release is installed, it > will look at the last applied patch number (stored in database) and > then run any new patches, each in its own transaction, and with some > sanity checking. > > There is also the tool LiquiBase, though I've never used it (yet?). > > /Oskar > > 2010/10/9 Timur Zanagar (ClockWorkZ) <[email protected]>: > > > > > Hi folks, > > > I just wanted to know if there are some best practices to handle > > changes for the database? > > > I looked into the discussion from 2008 (Schema Update in real world?) > > and it seems that there was the main opinion not to use SchemaUpdate > > in production environment. So what are the opinions today? Did > > something changed? How do you handle this? > > > -- > > You received this message because you are subscribed to the Google Groups > > "nhusers" group. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group > > athttp://groups.google.com/group/nhusers?hl=en. -- You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/nhusers?hl=en.
