Sharepoint 2010,Moss 2007

Thursday, March 15, 2012

Deploying an External Content Type, Error: The default web application could not be determined

Deploying an External Content Type, Error: The default web application could not be determined

Business Connectivity Services – Parte V

Wednesday, March 14, 2012

Deplying webpart

http://www.iplayerhd.com/playerframe/progressive/95624222-9076-4726-a4d1-b1d10cec540c.aspx?autostart=false&width=768&height=432&cbartype=bottom

difference between Site Columns and List Columns

The primary difference between Site Columns and
List Columns is reusability. Site Columns can be reused on any
lower-level site. List Columns are unique to the list or library in
which they are created.

After a long break, again I am back to write another blog post. I don’t have much work at office so you can imagine where I am investing time & energy. Yes, of course lots of coffee & debate with colleagues. Today’s most interesting argument was on confusion between site columns and List column
SharePoint Columns, Lists, and Content Types
0 out of 19 rated this helpful Rate this topic

Data models in SharePoint 2010 are implemented using columns, lists, and content types. A full understanding of these constructs underpins every effective data model in SharePoint 2010.
SharePoint Columns

The column, or field, is the core data construct in SharePoint 2010. In the context of the SharePoint platform and SharePoint applications, the terms "column" and "field" are used interchangeably:

"Column" is preferred in product documentation and is used in the SharePoint user interface.
"Field" is often used when referring to declarative markup or object model code. For example, columns are represented as Field elements in site or list definitions, as FieldRef elements in content type definitions, and by the SPField class in the SharePoint object model.

Ff798404.note(en-us,PandP.10).gifNote:
A FieldRef in a ContentType is a reference to an existing site column, instead of a column definition.

Columns can exist at two different scopes. You can create a list column, which exists only within a specific SharePoint list. You can also create a site column, which is defined at the site collection level and is made available for use in lists and content types across the site collection, including all subsites. Each site collection includes a site column gallery in which built-in and user-defined site columns are listed. When you create a column, you can define the following information:

Core details, including the column name and the data type
Group details, which can help you organize and find your columns within a site collection
Logical details, such as whether a value is required, whether the value must be unique, the maximum length of the value, and a default value, if appropriate
Validation details, including a validation formula and an error message

Ff798404.note(en-us,PandP.10).gifNote:
For more information about columns and fields in SharePoint 2010, see Building Block: Columns and Field Types and Columns on MSDN. You can also define columns at any site level, although the common practice is to define all site columns in the root site to maximize reuse within the site collection.

The ability to enforce unique column values is new to SharePoint 2010. The unique value constraint applies only at the list instance level. Uniqueness can be defined at the site column level, but it is enforced within each list. Because of the way the unique value constraint works, you must index any columns that enforce uniqueness. You can only apply unique value constraints to columns with certain data types, because some data types cannot be indexed. You can apply the unique value constraint to a column in three ways—interactively through the user interface, declaratively by setting the EnforceUniqueValues attribute in the column definition, or programmatically through the SPField class.
Ff798404.note(en-us,PandP.10).gifNote:
For more information about the unique value constraint for SharePoint columns and a list of column types that can be indexed, see Enforcing Uniqueness in Column Values on MSDN.

SharePoint Lists

Lists are the storage mechanism in the SharePoint platform. In some ways, lists are conceptually similar to a SQL database table, in that they are comprised of columns (or fields) and rows (or list items), and that you can create relationships between lists. SharePoint lists additionally provide a user interface including forms for interacting with the data. Unlike a database table, which typically has a constant predefined set of columns, the SharePoint list also allows users with sufficient permissions to add or remove columns at will.

Although it is possible to define a data model using only lists, the recommended approach is to use content types to define your key data entities.
SharePoint Content Types

Content types were introduced in SharePoint 2007 products and technologies. A content type defines the metadata and behavior for a particular data entity—usually, a business document or item of some kind. Each content type contains references to one or more site columns. You can also associate workflows, information management policies, and document templates with content types. For example, suppose you defined a content type named Contract. This content type might include the following:

Columns named Customer, Amount, and Final Effective Date
An approval workflow
A retention policy linked to the Final Effective Date field
A Word template for a contract document

Content types can be created in three ways. Site collection administrators can create content types interactively through the user interface without developer involvement. Developers can create content types declaratively by using collaborative application markup language (CAML) or programmatically through the SPContentType object model.

Content types are defined and managed at the site level, but they are typically defined at the root site in a site collection. In order to use a content type, you must associate it with a list or a document library. You can associate a content type with multiple lists or libraries, and each list or library can host multiple content types. This is useful in scenarios where different types of document share similar metadata—for example, you might store invoices and sales orders in the same document library, because both share similar fields but might differ in terms of approval processes or retention requirements. The ability to associate behaviors with a content type, such as workflows and event receivers, is comparable to the concept of triggers on a database table. However, because the content type can be applied to multiple locations, you can use content types to define a contract, purchase order, or invoice that has the same metadata—and the same behavior—across the entire organization.

When you associate a content type with a list or library, the content type is attached to the list, together with the site columns, workflows, and policies for that content type. These policies and workflows will apply to any item of that content type in the list. The following illustration shows this.

Associating content types with lists and libraries

Ff798404.a2fe80a2-db41-4298-a382-9a6257989319(en-us,PandP.10).png

Content types follow the concepts of inheritance, because many data entities will share common metadata and behaviors. For example, an Invoice content type would inherit from the Document base content type, because an invoice is a type of document and shares certain characteristics with other types of documents. Ultimately, all content types inherit from the Item base content type. For more information about content type inheritance, see Base Content Type Hierarchy on MSDN.

When you associate a content type with a list, the site content type is actually copied to the list and is given a new ID value that identifies it as a child of the site content type. The list content type is then said to inherit from the site content type. As a result, changes to a site content type are not reflected in individual lists and libraries unless you explicitly propagate, or "push down," the changes. If you update the content type programmatically, you can use the SPContentType.Update(true) method to propagate your changes—the Boolean argument to the Update method indicates that your changes should be applied to all child site and list content types. If you update the content type through the site collection user interface, you can select whether your updates should be applied to child content types. For more information, see Updating Content Types and on MSDN.