What do SQL Server, Social Media and SharePoint have in common? They are all things that we are learning, or still learning and they are all places where we just might make some mistakes. Earlier this week, one of my team members had to make a change to the structure of a table that we are using while testing our connections between SharePoint and our backend database. The change triggered that queasy-feeling-generating message about having to drop and recreate the table:
This young woman leans toward cautious; she started exploring the options for altering her approach. I’m not sure she appreciated my advice, which came wrapped in a question: “what’s the worst that can happen?” After all, it’s a test database. I tried to sweeten the deal by adding that “we might as well see if this works” and that even if it failed, it would “give our system administrator a chance to test his backup and restore process”.
While she was struggling with SQL Server, I was learning more about using social media in our business. I spent a good part of this past week at the Enterprise 2.0 Conference – Boston, now officially known as E2Social, listening to people talk about effectively using social media to promote or grow your business or using it to improve communication and collaboration within your organization. In all these sessions, one message came through clear – mistakes are going to be made. After reading this far, you probably won’t be surprised to learn that I’m not bothered by that fact; we’ve been making mistakes with SharePoint for years. The important thing to know about those mistakes is that none were very large, none cost our company
any much money and every mistake was a learning experience. Nathan Bricklin, Head of Social Strategy at Wells Fargo summed it up in his keynote presentation at E2. I’m paraphrasing here, but the quote I loved was:
“if you take baby steps and fall, you can learn walk. If you plan a project for a year and fail, you won’t be able to figure out what you did wrong”
The other feel-good moment in his presentation was when he reminded us that: “…it’s like baseball, you can’t win or lose the game in the first inning” that quote might not have been all that well received at this point in Boston, but we all understood the underlying message.
In our office, we have been playing this game all year as we have been experimenting with the various ways we can connect SharePoint to our backend data. We realize that if we can tie structured data to unstructured data, we can automate, or support through automation, a much more significant part of the target business process. Unfortunately, trying to make these connections has been underscoring why the word “frustrating” in in my tag line. We have managed to assemble successful proof-of-concept pages, parts, lists and workflows for almost every feature that we need to use. We have run into almost every error you can generate (they all seem to be related to permissions) and we have solved or worked around most of them. In short, we have fallen, but we are learning how to walk.
I never have much luck when I predict what next week’s post will be, but if things go according to plan, I’ll be sharing some of the specific experiences we have had with our connection quest. If things go according to history, I’ll be talking about something totally unexpected that will happen during the next few days.
By the way, if you want to know how to make it possible to let SQL Server drop and recreate those tables, see Geoffrey Emery’s excellent blog entry from 2009. I discovered that shortly after we began our migration from DB2 to SQL Server. DB2 warns you when a table has to be dropped and recreated, but it lets you decide whether or not you want to make the attempt. Unless you change your settings in SQL Server Management Studio, you get the warning shown above, but you can’t actually proceed. I will add for the faint of heart, that once you make the changes that Mr. Emery outlines, the drops and recreations just happen, no muss, no fuss, but no warning.