One thing about being around the industry since the days when dinosaurs roamed the Earth, is that you can get to be a little philosophical about the industry at times. There are two things that I've been thinking about again today, where we seem to be in total denial. One is EULAs; the other is passwords.
Has anyone tested EULAs in court lately? It's hard to imagine most of them being very enforceable. More importantly, does anyone EVER read them? I was amused a few years back when I was installing an application, clicked over the EULA and the application said "how could you possibly have read that in 1.076 seconds?". That's a fair cop.
Today though, it's the EULAs at the Apple AppStore that just seem totally stupid. A while back, I installed the genuine Twitter app on my iPhone. Previously I was using Halo. The new Twitter app seemed pretty cool, right up till the day it had an update available. On the screen of my phone, it kept prompting me to update it. So I thought "hey this is cool, I'll update it". To update the FREE application, I had to log in to the AppStore. Doing that on the phone is a bit cumbersome but ok. But after I did so, it tells me that I now need to agree to the new AppStore terms and conditions. Once I had done that, it then told me that I should try my "purchase" again.
But the super annoying thing is that EVERY time I go to update the Twitter app, the AppStore terms and conditions seem to have changed. So this happens EVERY time. But what really impresses me about this process, is that the terms and conditions that you need to agree to occupy 58 PAGES. Has ANYONE EVER read all those 58 pages? And do I really need to read and agree to 58 pages of terms and conditions every time I want to update my free Twitter app? On a phone? You have to be kidding. I'd love to see the page view statistics from Apple that show how many people have EVER retrieved most of those pages.
The other mild form of insanity that I'm thinking about today is passwords. We always tell users to:
- Use different passwords for every system
- Make the passwords very complex
- Change the passwords regularly
- Never write down the passwords
Users get blamed when they don't follow the rules but I'm sorry, is it even humanly possible to follow the rules? We have to stop this sort of nonsense if we ever want our industry taken seriously by the general public. And I think I have to go back to using Halo instead of the free genuine Twitter app.
And as for the courts, I can well imagine many judges not being too convinced about enforcing rules that it's almost impossible for a human to comply with.
I've been working with SQLCMD mode again today and one thing about it always bites me. If I execute a script like:
I'm sure I'm not the only person that would be surprised to see all three SELECT commands executed against SERVER3 and none executed against SERVER1 or SERVER2. If you think that's odd behavior, here's where to vote: https://connect.microsoft.com/SQLServer/feedback/details/611144/sqlcmd-connect-to-a-different-server-should-be-an-implicit-batch-separator#details
There was a short discussion on the SQL Down Under mailing list this morning about screen resolutions for working with the SQL Server tools. In particular, the issue was about how unusable the tools are on the 1366×768 resolution notebooks that now seem to be the most common. While finding a notebook with an appropriate resolution is obviously the answer at this time, I started thinking that the product itself needs to address this.
SQL Server tools currently target a portrait 4:3 shape for minimum window sizes. Increasingly, portrait 4:3 format monitors are disappearing from sale.
While I loved the standard portrait orientation and prefer to work in it, the world has decided that watching DVDs on computer screens is more important than real work. So sadly, I think the SQL Server tools should now target wide screen formats by default. If you think, as I do, that the SQL Server tools should now be designed to be at least workable on 1366×768, vote here: https://connect.microsoft.com/SQLServer/feedback/details/636373/sql-server-tooling-should-target-wide-screen-form-factors#details
One of the discussion lists that I participate in, had a brief discussion this morning about whether or not it's possible to perform log shipping between differernt versions of SQL Server. Specifically, can you do log shipping between SQL Server 2005 and SQL Server 2008?
SQL Server does support restoring earlier version databases on later versions of the product. The databases get upgraded along the way when you perform restores of databases. SQL Server also allows you to restore transactions logs from earlier versions of the product but (as Robert Davis points out in the comments below), the upgrade doesn't happen until recovery of the database occurs. And that's why you can't use STANDBY mode in this situation.
So, you can set up log shipping between versions, however things aren't that simple. Log shipping is often used to provide a warm standby. If you use it in this way and you need to fail over to the standby server, you now have now way to swap the log shipping roles, as you can't then log ship back from the 2008 server to the 2005 server.
If you are performing a one way log ship, intentionally, this might be quite acceptable to you. I often see log shipping used when servers are being upgraded from one version of SQL Server to another version, even side-by-side. When it's time for the swap to the new server to happen, the final logs just need to be moved and this takes very little time. There are other reasons as well as to why you might be happy to just have a one-way log shipping operation.
The main point is that you need to consider why you are performing log shipping before you do this. If it's with a view to swap roles from primary to secondary and back, then log shipping between versions isn't for you.
A year or two back, I was involved in a project with my colleagues (led by Ron Talmage) to construct an Upgrade Technical Reference for SQL Server 2008. It seemed to be well received.
We've updated it now to SQL Server 2008 R2 and it's just been published. You'll find it on this web site: http://www.microsoft.com/sqlserver/en/us/product-info/why-upgrade.aspx You'll need to click on the Upgrade Guide link towards the middle of the RHS under the "Why Upgrade" whitepaper.