Archive for the ‘SQL’ tag
SharePoint 2010: What We Know and What We Want
Since the announcing of SharePoint 2010 this month, the community has been buzzing with what we know about ‘10 and what we are still speculating about ‘10. There isn’t a whole lot of concrete information out there yet, but I’ve compiled a list below of what I’ve seen so far. I’ve also started listing some of the pressing things that we, the SharePoint community, would like to see in ‘10.
Confirmed:
- So long MOSS! It seems like you’ve been renamed to just Microsoft SharePoint Server. We’ve called you so many things over the years that we’re hoping this name will actually stick.
- PerformancePoint Monitoring & Analytics functions will be bundled into the Server license
- Users will be able to open/edit/save/collaborate on Office documents through a web browser
- Native support for ODF and PDF seems to be a safe confirmation as Office System SP2 will now support editing of both formats.
- All Forms Server functions bundled with 2010 – There are clients who signed on for Forms Server standalone for WSS installs, so it would be nice if they bundled it with the next equivalent of WSS. I have an unofficial confirm from an MS employee that features will be available in 2010 but no solid details so far.
- Standardized UI across all Office products, browsers, mobile devices
- Open API support
- FAST Search for Server Enterprise owners
- Upgrades to 2010 will rely heavily on the new upgrade scanning command in STSADM – available in SharePoint 2007 SP2
- 2010 Q1 or Q2 projected release date
Hopes/Wants:
- Native SQL tables for SharePoint lists – Ever since this interview with Bill Gates, I’ve hoped that this will actually come to fruition. But as with any Microsoft product, it can take 2-3 iterations to get a major feature like this once it’s mentioned.
- More out-of-the-box branding features
- Native Silverlight and AJAX support
- More advanced backup options
- Thanks for making SPD free, but we need it to be more useful and less frustrating!
- jQuery support
You can also visit SharePoint Buzz for their list of SharePoint 2010 features.
Please post anything that I’ve missed or something that you’d like to see in 2010.
5/12/09 UPDATE- New post here with more SharePoint 2010 details.
Sharepoint Update Log – Part 2
Part 1 Part 2
In Part 1 of this article I compared and contrasted the various methods that we could use for our Sharepoint update log application. I’ve chosen the custom aspx site/SQL table method as it is the most effective solution for what I currently need. I don’t intend to design a full-fledged application with reporting features, logins, AJAX menus(well.. maybe a little AJAX would be cool!), etc. I need a custom site that is independent of Sharepoint, so developers/admins can log their updates to the database. If Sharepoint breaks, then we should be able to access this data as it might help us determine the point of failure. Simple and effective.
My aspx site is uber-simple to the point to where you might question why I even spent time writing this article. Well, I’m glad you’re that concerned about my free time! I’m writing this, because I see a lot of IT shops without something like this. Keeping an update log for live servers should be a non-negotiable in your environment. I hope that this example will either offer you a solution that you can use immediately or provide you with a catalyst to design your own solution based on your needs. You don’t have to be a VB.NET guru to get this done. For this article, I’ll show you some screenshots, so you can laugh at see how simple this is.
- As you can see I have a few drop down boxes and text boxes that match the table layout from the previous article. I’m not sure if I can prove it, but I’m sure there’s a developer somewhere named John Madden.
- I’ve added the necessary information to the form, and I am ready to submit. The change log text box is basically just a multi-purpose field for people who want to link to the actual change log or other document explaining what this update is for. This example links to the Microsoft page pertaining to the KB article. This could also be used for relative locations on the local network.
- Click submit, and the data is added to the database table! Praise be to ASPX.
I hope that you can now see how easy this is to do, but also how effective it is for keeping an accurate log of what you’re updating on the servers. This solution would probably suit small to medium-sized operations the best, as the big boys generally have enterprise software to handle this.
Another plus about this solution is that you can use Sharepoint as the front-end by using the BDC or Bamboo’s MashPoint, host the site by itself via IIS, or do both and connect to it with a web part. Part 3 will cover these options and conclude the series.
Sharepoint Update Log – Part 1
Part 1 Part 2
It’s not everyday that you find a company or IT department that keeps a structured and updated “update log” for their systems, let alone Sharepoint. Updating your software is as easy as clicking a few buttons and trusting that everything will work as advertised. And for the most part, application updates really do what they are supposed to without causing outages. With communities, blogs and wikis for just about every application in existence, developers find it much easier to distribute test builds to the masses and receive responses rather quickly. This translates to quicker bug fixes and an overall better experience for end-users. But this can also lead to an ultra-trusting mentality when it comes to updating your software with major upgrades and/or patches. It only takes one patch to create hours of work for you and your team to get the system back online when incompatibilities rear their ugly heads.
This three part article will aim to give you my thoughts for an effective update log for your Sharepoint servers.
NOTE: I’ve written this article with respect to Sharepoint specifically. It is part of a larger concept that could be incorporated into all LOB systems.
The first thing that we need to do is figure out where we should store our data. Depending on your needs and organizational size this may be a very simple setup, but it still helps to think it through first.
The table below summarizes a few pros and cons for 4 possible scenarios.
| Location | Pros | Cons |
|---|---|---|
| Text file | Super easy to maintain, extremely portable, zero learning curve | Poor security, no formatting capabilities, no reporting capabilities, easily misplaced or deleted |
| Microsoft Excel | Easy to maintain, better security, virtually unlimited formatting capabilities, sorting and simple querying, easy to export data | Low security, does not achieve zero-client architecture, easily misplaced or deleted |
| Sharepoint list | Simple to setup, maintain and share, useful formatting and sorting features, most cost-effective | Dependent on site availability |
| SQL database | Complete data independence, superior security features, better audit trail, can be tailored for any scenario | Least cost-effective, requires intermediate DBMS and programming knowledge |
This is a pretty self-explanatory table, but I want to touch on one of these a little bit deeper. When thinking of an update log for Sharepoint servers, the first thing that comes to mind would be an easy to maintain Sharepoint list. It is by far the quickest way to get data in a nice format that others can read/edit. But this option does not accomplish enough independence from the platform itself. If your Sharepoint farm is down, then you’ve negated the update log completely. So although Sharepoint may be an option for you (if you aren’t worried about a severe failure), I would recommend not storing your data in a native Sharepoint list.
With that said, I’ve chosen to store my data in a custom table on MS SQL Server 2005. The below query will get you started with a simple update log table to store your data. You can change the structure below to match your naming system, but make sure that you are not adding this table to any of your existing Sharepoint content databases. It can be tempting to store this data in your default Sharepoint content database for ease of use, but that comes along with a higher security/corruption risk. And although I haven’t tried this long enough to see if it will break something in Sharepoint (like a restore process), play it safe and create a separate database. I’ve called mine “admin” to keep things simple.
USE [admin]
GO
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE TABLE [dbo].[sp_updates](
[id] [int] IDENTITY(1,1) NOT NULL,
[developer] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the developer of the update
[application] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the application affected
[type] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the type of update applied
[number] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,
–Identifies the update number or KB number for Microsoft updates
[change_log] [nvarchar](50) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
–Refers to a UNC path or HTML link to a change log file
[date] [datetime] NOT NULL
) ON [PRIMARY]
Stay tuned for the next article where I will show you a small custom aspx site that will access this table. Furthermore, in the third and final article on this subject, I will display the best of both worlds. It will cover the usage of Sharepoint as a front-end display for your update log, while still maintaining a level of data independence.
Your feedback is always welcome!
