Indexed column in SharePoint List

Indexed column in SharePoint list is used to improve performance of query to work with large list efficiently.

You can create index on single column (Specify primary column for index) or specify compound index on two columns (Specify primary & secondary column for index).

SharePoint list instance support a maximum of 20 indices.

Not all the field types can participate in composite index.

When you create an indexed column, it requires extra storage space to maintain it and also adds unnecessary overhead. So you should create index only to columns that will be used in filtering view on list.

Managed metadata navigation and filtering require indexing column on list.       

Indexed column also affect the throttling for list that contains large amount of items.

Suppose you build query that returns first 100 items from non-indexed Title column with sort, then query would have to scan all the items from list in content database to define the sort order for first 100 items. Due to that query become throttled. To avoid such issue, create index on Title column to returns the first 100 sorted items instead of scanning all the list items from content database.

Not all column types can be indexed. Following table shows supported and unsupported column types for indexing in list.

Supported column types	Unsupported column types
Single line of text	Multiple lines of text
Choice field having single value	Hyperlink or Picture
Number	Calculated field
Date/Time	Yes/No
Lookup (Single value)	Custom field type
Person or group (single value)	External data
Currency
Title (only in list)
Managed metadata

How to create index column in list:

1. Navigate to SharePoint List >> List Settings
2. Click on Indexed Columns

3. Click on Create Index link

4. Select Primary column as Title from the drop down list and keep secondary column as blank if we do not require any compound index column.

5. Click on Create button to generate new index column and will display as below. You can also edit the indexed column by clicking on it.

 

Enjoy SharePoint!!!

Difference between Web Part and Visual Web Part

Web Part	Visual Web Part
In Web part, everything has to done through code for UI as well as logic. It does not provide visual UI effect. Hence it affects the productivity.	Visual web part is a web part which contains the reference of user control in which we can place controls from designer and have separate code file to add business logic inside it. It improves the productivity to design the complex UI.
Web part can be deployed as a sandbox solution hence it will not impact the whole farm if any issue with simple web part code.	In SharePoint 2010,Visual web part cannot be deployed as a sandbox solution. It can be deployed as a farm solution. You can use Visual studio 2010 SharePoint power tools extension to deploy visual web part as a sandbox solution. Power tool generate the complied code with user control as a part of assembly Few SharePoint or Asp.Net web controls are not supported in sandbox solution due to that visual web part gives an error occasionally.
Web part can be extended by inheriting from the WebPart class. We cab reuse the web part functionality.	Visual web parts cannot be extended.
Web part does not affect the performance compare to visual web part.	It has user control and web part inside it, thus it takes long time to load the user control due to that it affects the performance.
Declaring web part properties and connection is easily doable in simple web part as code is written in web part itself.	It is awkward to manage the web part properties and connection declaration in visual web part as it has includes multiple files.

Note: In SharePoint 2013, there is only one template to create web part named SharePoint 2013 Visual Web Path which include the user control in solution as complied assembly that can be deployed as sandbox solution.

Enjoy SharePoint!!!

SharePoint 2013 Apps

SharePoint 2013 Apps are self-contained pieces of functionality that can be used to extend the SharePoint web site functionality.

SharePoint 2013 App runs outside of SharePoint environment.

SharePoint App can be easily provision on site and to be removed cleanly as no longer need.

Apps can available for user through app catalog or SharePoint Store.

Microsoft has introduced the new app model in SharePoint 2013 to overcome the limitations of SharePoint sandbox solution. Sandbox solutions are depreciated in SharePoint 2013.

1. Apps must be supported in Office 365 and in on-premises farms.
2. App code never runs within the SharePoint host environment.
3. App code programs against SharePoint sites by using web service entry points to minimize version-specific dependencies.
4. App code is authenticated and runs under a distinct identity.
5. App permissions can be configured independently of user permissions.
6. Apps are deployed by using a publishing scheme based on app catalogs.
7. Apps that are published in a catalog are easier to discover, install, and upgrade.

Types of SharePoint 2013 Apps:

SharePoint Hosted App: SharePoint hosted apps are installed on on-premise SharePoint 2013 environment and it’s called host web. So, all the resources are hosted on on-premise or Office 365 environment. Apps get authorized by using internal authentication means single sign in user. No serve code allowed, only client side java script code is used.

Cloud Hosted App (Auto Hosted App & Provider Hosted App):

Provider hosted apps are installed on host web, but remote components are hosted on another server. Apps are deployed and hosted outside the SharePoint farm environment. Apps get authorize by OAuth or JavaScript Cross domain library.

Auto hosted apps, remote components are provisioned and deployed on Microsoft Azure. Apps get authorize by OAuth or JavaScript Cross domain library. Like Provider hosted app, auto hosted app interact with SharePoint site and uses resources that are located at remote site.

Note: Microsoft announced an end of auto hosted app preview. Click here on link below for more details.

http://blogs.office.com/2014/05/16/update-on-autohosted-apps-preview-program/

Why Apps for SharePoint introduced? Or Limitation and constraints of SharePoint Solution

1. Custom code runs within the SharePoint host environment that results in creating problem of stability of farm.
2. Up gradation of on-premise SharePoint farm to new version of SharePoint. In this case there is a lot of rework for custom code development of SharePoint Solution.
3. Security and Permissions concerns with SharePoint Solution development. Running of custom code inside sandbox solution is not protects the content of farm. It protects against the farm and site collections of it.
4. Impersonation issue with Sandbox solution. Sandbox solution runs under the context of current user privileged in SharePoint.
5. To install solution on farm requires the farm administrator permission and IIS reset on all the WFE servers which affect end users work.

Required Service Applications for SharePoint 2013 Apps:

SharePoint 2013 uses two service applications to manage the environment for App for SharePoint.
App Management Service: It is new service introduced in SharePoint 2013.
The App Management Service has its own database that is used to store the configuration details for apps as they are installed and configured. It is also responsible for tracking other types of app-specific configuration data that deals with app security principals, app permissions, and app licensing.

• App Instance metadata
• App security principals
• App Permissions
• App Licensing

Creating an instance of the App Management Service is easier because it can be done manually via Central Administration or by using the Farm Creation Wizard.

Site Subscription Setting Service: It was introduced in SharePoint 2010.
Site Subscription Settings Service is used to manage tenancies. Each time a new tenancy is created; this service adds configuration data for it in its own database. The Site Subscription Settings Service is particularly important to the SharePoint app model due to this requirement SharePoint apps must always be installed and run within the context of a specific tenancy.

• Tenancy management
• Site Collection mapping

Creating an instance of the Site Subscription Settings Service is a bit trickier because it must be done by using Windows Power shell. However, when you create an instance of the Site Subscription Settings Service by using Windows Power shell, it automatically creates the default tenancy, which then makes it possible to install SharePoint apps in sites throughout the farm.

A SharePoint 2013 tenancy is a set of site collections in either a SharePoint farm or in SharePoint Online.

App Installation Scope:

Site Scope: The app is installed and launched within the scope of the same SharePoint site. In this scenario, the host web will always be the same site where the app has been installed.

Tenant Scope: In which host web cannot be the same site where the app has been installed.
In this scenario, an app is installed in a special type of SharePoint site known as an app catalog site. After the app has been installed in an app catalog site, the app can then be configured so that users can launch it from other sites.


Enjoy SharePoint!!!