One of the most interesting things I saw at Southwest Fox was Tuvia’s presentation of dbSchema (see his white paper for all the great things about dbSchema). I rushed home, got it installed, and … ran into some issues. It’s still a great tool that I’ll be using, just not quite as great as I hoped. Here are the issues I’ve run into:
In theory: With dbSchema, I’ve got one schema for my development database and then at the client I’ve got a schema for the production database. When I’m ready to go live, I just compare the two schemas and it’ll show me the differences and update my production database.
In reality: dbSchema is reporting a lot of differences that don’t appear to be differences:
This might be because my development server is SQL 2012 while the client is SQL 2005. Maybe if I went ahead and made those changes, the differences would go away. I haven’t been brave enough though to make a couple thousand changes to the production database.
I had hoped this would be automatic, instead I have to hunt through this list to find the actual changes. Still better than having to remember the changes or document them as I develop.
dbSchema has a great tool called Layouts that you can use to document your database. It can show what tables are linked to what, what the keys are, add comments, etc. My client in this case is pretty tech savvy and I was excited to do the Layouts in development and then synch them up to the production schema.
Alas, the compare schema function does not synch the layouts. I can’t find a way to export/import a layout from one schema to another.
You could get around this by having just one schema – just replace the production one, but that then erases any work the client did.
dbSchema has a cool tool that exports all of your layouts to HTML which is nice. Each layout goes to a separate HTML page. There is not an index page or a way to navigate from one page to another page though. Minor annoyance.