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.

sp_update_log1

  • 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.

sp_update_log2

  • 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.

sp_update_log3

  • 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.