Tuesday, October 2, 2012

SharePoint site templates vs site definitions.

Site Template
  • A site template (*.stp file) is created through the user interface or through implementation of the object model. It is a package containing a set of differences and changes from a base site definition.
  • The site template package is stored as a CAB-based file that can be downloaded or uploaded to site collections by users with the appropriate rights. As before, site templates offer a measure of portability to SharePoint Applications.
  • It is not as fast as a pure site definition as site definitions are cached on start of IIS on the web front ends while site templates are stored and hence need to be fetched from the content database and merged with the site definition code at runtime to render the site.
  • Also note that if you plan to transfer a site template to separate farm, that the farms have the same versions installed of SharePoint installed.  (hotfixes,etc.) This is due to the dependence site templates have on the original base site definition they were created from.
Site Definition
  • The core definition of what a site is in SharePoint.
  • It is installed on file system of web front ends, located at ..\12\Template\SiteTemplates. This directory is language-neutral.
  • It consists of .aspx pages and .xml files with Collaborative Application Mark-up Language (CAML).
  • A major benefit is that the Page and List definition is read locally from the file system, not from Content Database.
  • A site definition Page and List definition are cached at the IIS process start up
  • Customizations made to site definition are stored in content database, not on the file system. This can be performed via SharePoint Designer, or when custom site templates are saved.
  • Site Definitions are developer created
  • Localization: WSS 3.0 supports full site template localization (based on ASP.Net 2.0 via XML files and .ASPX files pulling strings from RESX files. Therefore solutions can be shipped “language packs” of resource files.
  • “Global Template” defines commonality across site definitions; it gets called before any other template. It works by injecting common provisioning content into all new sites. ONET.XML file defines base types, galleries, mobile redirects
  • Data is stored directly on the Web servers, so performance is typically better.
  • A higher level of list customization is possible through direct editing of a Schema.xml file.
  • Certain kinds of customization to sites or lists require use of site definitions, such as introducing new file types, defining view styles, or modifying the Edit menu.
  • Customization of site definition requires more effort than creating custom templates.
  • Editing a site definition after it has been deployed is difficult.
  • Doing anything other than adding code can break existing sites.
  • Users cannot apply a SharePoint theme through a site definition.
  • Users cannot create two lists of the same type with different default content.
  • Customizing site definitions requires access to the file system of the front-end Web server.
  • Custom templates are easy to create.
  • Almost anything that can be done in the user interface can be preserved in the template.
  • Custom templates can be modified without affecting existing sites that have been created from the templates.
  • Custom templates are easy to deploy.
  • Custom templates are not created in a development environment.
  • Custom templates are less efficient in large-scale environments.
  • If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template does not work.

Custom site definitions hold the following advantages over custom templates:

  • Data is stored directly on the Web servers, so performance is typically better.
  • A higher level of list customization is possible through direct editing of a Schema.xml file.
  • Certain kinds of customization to sites or lists require use of site definitions, such as introducing new file types, defining view styles, or modifying the Edit menu.


Site definition disadvantages include the following:

  • Customization of site definition requires more effort than creating custom templates.
  • Editing a site definition after it has been deployed is difficult.
  • Doing anything other than adding code can break existing sites.
  • Users cannot apply a SharePoint theme through a site definition.
  • Users cannot create two lists of the same type with different default content.
  • Customizing site definitions requires access to the file system of the front-end Web server.


Custom templates hold the following advantages over customization of site definitions:

  • Custom templates are easy to create.
  • Almost anything that can be done in the user interface can be preserved in the template.
  • Custom templates can be modified without affecting existing sites that have been created from the templates.
  • Custom templates are easy to deploy.


Custom template disadvantages include the following:

  • Custom templates are not created in a development environment.
  • Custom templates are less efficient in large-scale environments.
  • If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template does not work.




SQL Collation


A collation itself specifies the rules for how strings of character data are sorted and compared. The rules for sorting data vary depending on the language and locale. For example if you was to use a Lithuanian collation, the letter "Y" would appear between "I" and "J" if sorted. And if using the traditional Spanish collation "ch" would be sorted at the end of a list of words beginning with "c".

More details here

Even within a table you could have different collations. Collation is a column property, therefore you would need to change the collation for each column: http://www.sqlusa.com/bestpractices/changecollation/

From here

Thursday, August 23, 2012

Native SharePoint upgrade from 2003 to 2010/2013



Well, believe it or not, there are still a large number of SharePoint 2.0 users out there. Yes, that is 2.0… as in 2003… as in 9 years old. At this point, those users are contemplating one of two things: start from scratch on 2010, or actually take the time to upgrade their current 2003 environment(s) to 2010 (or even 2013).
Needless to say, the upgrade path from 2003 to 2010 can be a bit overwhelming. Just like all previous majorreleases of the SharePoint product, there is no way to upgrade directly from 2003 to 2010; you must first upgrade from 2003 to the 2007 version. I know it sounds complicated, but before you decide to scrap everything and start from scratch, let’s take a closer look at what’s involved for the upgrade process.Speaking from experience, making the upgrade from 2003 to SharePoint 2010 isn’t really as tough as it sounds.
The most difficult part of the upgrade is having the required hardware and software, as well as space available to backup the environment in case any issues arise during the upgrade. *It may seem obvious to some our readers, but it’s worth noting that upgrading to SharePoint 2010 will take an entire new server utilizing 64-bit hardware.