An early peak at the bloopers going out on Monday. Feel free to enjoy today. I’ve included the editorial and then the raw bloopers from the last month, which has a few more mistakes in there.
The raw ones are below, and include the ones above plus a few more that didn’t make the cut.
One of the things I’ve found is that so many people struggle to get started with SQL Server. There are regular questions about how to learn to work with SQL Server, so I built this quick talk that should help you get started.
This talk is built on the 80/20 rule, the idea that 80% of your job needs 20% of the DBA skills, and vice versa. So these are a series of skills, presented quickly, that should get you through most of the things that you need to deal with in SQL Server as an administrator.
Developers will find that spending a little time learning these skills will also let them easily setup a SQL Server instance that can maintain itself for the most part without them. And it will protect them in the event there are issues.
The talk moves quickly, but there are lots of links and references in the deck.
The slides are on my SkyDrive.
This talk is built for 60-75 minutes
These are the blog posts related to this talk:
T
his editorial was originally published on Oct 25, 2005.
Does your company offer a sabbatical? Andy and I were discussing retention and benefits awhile back and we got around to sabbaticals. He was trying to secure this benefit for his development staff, and I’d had a little experience, so we got to talking. I’ve never personally had one, but my wife has. She worked for a high tech company in the 90s and after 6 years, she was allowed to take 6 weeks, full salary, as a sabbatical.
I’ve never personally worked at a company where it was offered, much less stuck around long enough to earn one. But I’ve always thought they were a great idea, without really understanding the purpose. It seemed like a great reward to let someone get a little extra time off after devoting six or seven years to the company, which seemed to be the norm with my friends.
However I started to research this a little and found that the idea wasn’t extra vacation. It was to allow someone to recharge, but in a constructive way. In academia, this usually means working on some defined project, a paper, book, or something else that has a tangible and specific end to it.
That is an interesting idea. When my wife took her sabbatical, she basically took 8 weeks of vacation; the sabbatical and some other PTO time she’d shared. For her it was a project, to try and be a stay at home Mom, but it wasn’t something defined with her employer. I’ve spoken to a few other people that were lucky enough to get them and it was really a vacation time for them, a chance to get away.
I think that setting up a sabbatical is hard. You don’t want to just pile up work for someone that takes off for 6 weeks, especially if there’s a chance they will not return. And if they return to something like that, it’s more of a punishment than a reward. Allowing someone to leave for an extended period, and I’d argue that 6 weeks isn’t that long, but it is hard on a company and the other employees. But I think it’s almost a necessity given the long hours and extra efforts that many IT people put in.
The idea of setting up a specific project, even something like attending a cooking school or training for a marathon, is a good one. There should be some flexible rules that bound the time, but still make it productive for the employer. Xerox has a great volunteer sabbatical where employees can spend a number of weeks volunteering with some organization, and I think that is outstanding.
I think I’d enjoy 6 weeks of pounding nails with someone like Habitat for Humanity.
There was confusion recently with a poster that was moving permissions around and asked why I said they should revoke permissions and not deny them. I decided this was worth a post to explain.
If I GRANT SELECT (or UPDATE/INSERT/DELETE) permissions to a user, then they can use those permissions to view data in a table. If I REVOKE the permissions, it’s the same as if the user never had them. They would need to be GRANTed permissions again to see the data.
However, if I DENY them the ability to see data, then that’s different. They can’t see the data, but a subsequent GRANT will not allow them to see the data because the DENY will still be in effect.
It’s a more permanent change, and should be used when you need to be sure that someone cannot see data, not when you are looking to remove permissions. To undo a GRANT, use REVOKE.
