SanDroid (3/10/2011)The amount of time these tools save you are worth any system lag you may experiance.

SanDroid (3/10/2011)

---

If you have a good dev system with plenty of memory, more than one CPU core, and you are not running 32bit windows install on 64bit hardware importing Databases with almost 8000 objects are no real problem..

Duncan Pryde (3/10/2011)

---

The second one does look like it might swing it. Up to now, we've tended to hand-write upgrade and rollback scripts for each release. It works, but it's time-consuming and quite clunky. I imagine this would be an improvement on that approach.

dave.farmer (3/10/2011)
For our last release, however, another developer did the release, and while he started with a generated deployment script he couldn't be bothered to follow my established procedure (one script per DB into test, and a second after bug-fixes, so you have a part 1 and a part 2 script to run on production eventually - maybe a part 3 if the bug fixes needed further fixing) and instead hand-cranked extra items into it rather than generating a catch-up script from the testing phase... we've spent a few days tracking down and fixing the errors he introduced! Missed procedures, one procedure that was created with a rogue "drop procedure..." statement after it so every time it ran it dropped another procedure, missing static data... all manner of issues!