If you see a blank page and error http://go.microsoft.com/fwlink?LinkID=96177 on it, when you browse your SharePoint web site, you should upgrade your Sharepoint.
To solve this, try this command:
stsadm –o upgrade –inplace [-url http://yoursite]
It helped me. Hope you too.
Thursday, September 4, 2008
Wednesday, June 6, 2007
Optimized items inserting into SPList
Well, when you try to Insert items in your list, you should remeber this.
Tips for writing performance optimized code for SharePoint
So advice from DkmS is write code like this:
const string EmptyQuery = "0
public static SPListItem AddItem(SPList list)
{
SPQuery q = new SPQuery();
q.Query = EmptyQuery;
return list.GetItems(q).Add();
}
Instead of SPListItem newItem = list.Items.Add(); use
SPListItem newItem = AddItem(list);
Tips for writing performance optimized code for SharePoint
So advice from DkmS is write code like this:
const string EmptyQuery = "
public static SPListItem AddItem(SPList list)
{
SPQuery q = new SPQuery();
q.Query = EmptyQuery;
return list.GetItems(q).Add();
}
Instead of SPListItem newItem = list.Items.Add(); use
SPListItem newItem = AddItem(list);
Monday, June 4, 2007
Column, Field, Property
Today I want to address a piece of SharePoint terminology that confused me no end when I first started working on the products. So, as a service to beginning SharePoint programmers the world over, here’s a quick (and hopefully precise, if not definitive) overview of three terms that tend to be used to mean the same thing: column, field, and document property.
Columns on Sites and Lists
Basically, what all three terms refer to a specific piece of metadata on a SharePoint item.
In other words, this:
In the UI, these are called ‘columns’ because, well, that’s what they are displayed as: columns. Each piece of metadata you’re collecting for a list is represented as a column on that list (Whether the column is actually displayed on the list or not. Columns can be hidden.)
However, if you take a look under the hood, either in the SharePoint schemas or object model, you’ll find they’re called Fields. This is what they were called in V2, and for compatibility sake, that’s what they remain in V3. (Database columns tend to be called ‘fields’, so that might be where the term originally crept in.)
So far, that’s all pretty straightforward. But V3 adds some complexity (and correspondingly, much flexibility and power) with the addition of content types, and site columns. I’ve talked some about content types here. Site columns can be thought of as templates; you create the site column at the site level, then you can apply it to the various lists and sub-sites as you wish. Site columns are represented as elements in the site schema, and Field objects in the object model.
When you add a site column to a list, the column definition is copied locally to the list, as a list column. So, in the list schema, the list column is represented by a element in the list schema now. In the object model, it’s represented by a Field object.
Another important point to mention: when you add a site column to a list, the resulting list column has the same field ID as the site column. SharePoint uses this to track which list columns are “children” of a given site column. This enables you to make changes to a site column and propagate those changes out to all the list columns that are children of the site column.
You can also create columns at the list level. These columns only apply to the list on which they are created. You can think of them as one-offs. You can add list columns to content types on that list, but that's it. List columns are also represented as elements in the list schema, and SPField objects in the object model. Because they were created from scratch, though, they do not have a parent/child relationship with any other column.
Columns in Content Types
Here’s where it gets interesting:
If there’s certain item metadata you want to track in a content type, you include a column that represents that metadata. However, you cannot create a column in a content type; rather, you have to create the column, and then reference that column in the content type definition. Because of this, when you add a column to a content type, the content type schema doesn’t contain a element, it contains a element. This is true of both site and list columns you add to content types.
The element is a reference to a column defined elsewhere, either at the site or list level. In the field reference, you can override a subset of the column properties, such as:
Display name
XML promotion and demotion attributes
Whether the field is read-only, required, or hidden
Changing these properties in the field reference only changes them as they apply to the specific content type that contains the field reference, of course.
Field references retain the same field ID as the column they reference.
If you create a content type based on a parent content type, be default all the columns in the parent are included in the child content type, as elements.
Now, when you add a content type to a list, the columns referenced in that content type get copied locally onto the list as list columns. In other words, the columns referenced by the various elements in the content type schema are copied onto the list schema as elements—again, with the child/parent relationship to the site column.
As mentioned earlier, when you add a list column to a list content type, it's added as a in the list content type schema.
Therefore, columns are always represented by elements in site and list schemas, but always represented by elements in content type schemas.
Field references in content types are represented by the SPFieldLink object in the SharePoint object model.
Document Properties
The term 'document property' is most often used in the context of talking about a particular piece of metadata you're interested in tracking for a document. That is, the particular column value for that document. The last modified date, for example. When you upload a bunch of documents and display the last modified date for each, you get a column of last modified date values, as in the screen shot above.
The document property might be something you're tracking solely at the document library level, or it might also be included in the document itself.
(In which case, WSS V3 includes functionality that enables you to promote and demote the document property, so the value in the document is always in synch with the value in the column.
Property promotion refers to extracting document properties from a document, and writing those property values to the appropriate columns on the document library where the document is stored. Property demotion refers to taking column values from the document library where a document is stored, and writing those column values into the document itself.
WSS includes several built-in document parsers that automatically promote and demote document properties for well-known file types. In addition, you can use the built-in XML parser to promote and demote properties from your custom XML files. Finally, WSS also includes a document parser interface, which enables you to build custom parsers that can promote and demote document properties from your custom file types.)
Hopefully, the figure below illustrates this relationship. You add the site column Author to a content type; in the content type schema, the column is represented by a element. When you add the content type to a list, WSS adds the Author column as a element. Both elements have the same field ID as the Author site column. When you add the list column ItemNo to the list content type, WSS adds it as a element, with the same field ID. For Document C, the actual values for those two columns are stored in the document itself, and also displayed in the columns on the list.
The Bottom Line
So, to review:
What are called columns in the user interface are referred to as fields in the schema and object model.
You can create columns at two levels: the site, and list levels. These columns are represented as elements in the site and list schema, and Field objects in the object model. List columns created when you add a site column to a list retain a child/parent relationship with the site column, and retain the same field ID as the site column.
You cannot create a column in a content type. When you add a column to a content type, it's added as a in the content type schema. When you add a content type to a list, the columns referenced by the elements in that content type schema are added to the list as elements.
Therefore, columns are always represented by elements in site and list schemas, and always represented by elements in content type schemas.
Document properties usually just refer to a field as it applies to a specific document. The document property might be something you're tracking solely at the document library level, or it might also be included in the document itself.
Postscript: A Short Digression Concerning the SPContentType Object
In the SharePoint object model, the SPContentType object contains both a SPFieldLinkCollection and an SPFieldCollection object. But if columns in content types are represented by field references, how can you have a collection of fields in the content type? Because it's one of the ways we're making your life easier, that's why.
The SPFieldCollection in the SPContentType object enables developers an easy way to get a 'merged view' of a column's attributes, as they are in that content type. By merged view, I mean all the attributes of a field, merged with those attributes that have been overridden in the field reference. When you access a field through SPContentType.SPFieldCollection["myField"], WSS merges the field definition with the field reference and returns the resulting SPField object to you. That way, you don't have to look up a field definition, then look up all the attributes in the field definition overridden by the field reference for that content type. We do it for you.
Because of this, there's a 1-to-1 correlation between the items in the SPFieldLinkCollection and SPFieldCollection objects. For each SPFieldLink you add to a content type, we add an SPField object that represents the merged view of that column as it's defined in the content type. You cannot directly add or delete items from an SPFieldCollection object in an SPContentType object; trying to do so throws an error.
Columns on Sites and Lists
Basically, what all three terms refer to a specific piece of metadata on a SharePoint item.
In other words, this:
In the UI, these are called ‘columns’ because, well, that’s what they are displayed as: columns. Each piece of metadata you’re collecting for a list is represented as a column on that list (Whether the column is actually displayed on the list or not. Columns can be hidden.)
However, if you take a look under the hood, either in the SharePoint schemas or object model, you’ll find they’re called Fields. This is what they were called in V2, and for compatibility sake, that’s what they remain in V3. (Database columns tend to be called ‘fields’, so that might be where the term originally crept in.)
So far, that’s all pretty straightforward. But V3 adds some complexity (and correspondingly, much flexibility and power) with the addition of content types, and site columns. I’ve talked some about content types here. Site columns can be thought of as templates; you create the site column at the site level, then you can apply it to the various lists and sub-sites as you wish. Site columns are represented as
When you add a site column to a list, the column definition is copied locally to the list, as a list column. So, in the list schema, the list column is represented by a
Another important point to mention: when you add a site column to a list, the resulting list column has the same field ID as the site column. SharePoint uses this to track which list columns are “children” of a given site column. This enables you to make changes to a site column and propagate those changes out to all the list columns that are children of the site column.
You can also create columns at the list level. These columns only apply to the list on which they are created. You can think of them as one-offs. You can add list columns to content types on that list, but that's it. List columns are also represented as
Columns in Content Types
Here’s where it gets interesting:
If there’s certain item metadata you want to track in a content type, you include a column that represents that metadata. However, you cannot create a column in a content type; rather, you have to create the column, and then reference that column in the content type definition. Because of this, when you add a column to a content type, the content type schema doesn’t contain a
The
Display name
XML promotion and demotion attributes
Whether the field is read-only, required, or hidden
Changing these properties in the field reference only changes them as they apply to the specific content type that contains the field reference, of course.
Field references retain the same field ID as the column they reference.
If you create a content type based on a parent content type, be default all the columns in the parent are included in the child content type, as
Now, when you add a content type to a list, the columns referenced in that content type get copied locally onto the list as list columns. In other words, the columns referenced by the various
As mentioned earlier, when you add a list column to a list content type, it's added as a
Therefore, columns are always represented by
Field references in content types are represented by the SPFieldLink object in the SharePoint object model.
Document Properties
The term 'document property' is most often used in the context of talking about a particular piece of metadata you're interested in tracking for a document. That is, the particular column value for that document. The last modified date, for example. When you upload a bunch of documents and display the last modified date for each, you get a column of last modified date values, as in the screen shot above.
The document property might be something you're tracking solely at the document library level, or it might also be included in the document itself.
(In which case, WSS V3 includes functionality that enables you to promote and demote the document property, so the value in the document is always in synch with the value in the column.
Property promotion refers to extracting document properties from a document, and writing those property values to the appropriate columns on the document library where the document is stored. Property demotion refers to taking column values from the document library where a document is stored, and writing those column values into the document itself.
WSS includes several built-in document parsers that automatically promote and demote document properties for well-known file types. In addition, you can use the built-in XML parser to promote and demote properties from your custom XML files. Finally, WSS also includes a document parser interface, which enables you to build custom parsers that can promote and demote document properties from your custom file types.)
Hopefully, the figure below illustrates this relationship. You add the site column Author to a content type; in the content type schema, the column is represented by a
The Bottom Line
So, to review:
What are called columns in the user interface are referred to as fields in the schema and object model.
You can create columns at two levels: the site, and list levels. These columns are represented as
You cannot create a column in a content type. When you add a column to a content type, it's added as a
Therefore, columns are always represented by
Document properties usually just refer to a field as it applies to a specific document. The document property might be something you're tracking solely at the document library level, or it might also be included in the document itself.
Postscript: A Short Digression Concerning the SPContentType Object
In the SharePoint object model, the SPContentType object contains both a SPFieldLinkCollection and an SPFieldCollection object. But if columns in content types are represented by field references, how can you have a collection of fields in the content type? Because it's one of the ways we're making your life easier, that's why.
The SPFieldCollection in the SPContentType object enables developers an easy way to get a 'merged view' of a column's attributes, as they are in that content type. By merged view, I mean all the attributes of a field, merged with those attributes that have been overridden in the field reference. When you access a field through SPContentType.SPFieldCollection["myField"], WSS merges the field definition with the field reference and returns the resulting SPField object to you. That way, you don't have to look up a field definition, then look up all the attributes in the field definition overridden by the field reference for that content type. We do it for you.
Because of this, there's a 1-to-1 correlation between the items in the SPFieldLinkCollection and SPFieldCollection objects. For each SPFieldLink you add to a content type, we add an SPField object that represents the merged view of that column as it's defined in the content type. You cannot directly add or delete items from an SPFieldCollection object in an SPContentType object; trying to do so throws an error.
Friday, May 11, 2007
Deploy a template to multiple SP form libraries
There are times when you want to deploy a template to multiple SharePoint form libraries. For example multiple teams may use the same template but need to keep their documents separate.
The typical way to do this is to deploy the form twice, once for each library. However, a few problems arise when you do this:
• If a user tries to open a form from the other library, they will get the form conflict dialog even though the form is supposed to be the same.
• A user who has cached a form from one library, cannot view forms from the other library offline. InfoPath thinks they're different.
• To deploy form updates the form you have to republish to each library separately.
There is a little known feature whereby you can publish the XSN template to one location and then reference it in multiple SharePoint form libraries. The steps to do this are as follows:
• Deploy the XSN to your shared location. It can be on the same SharePoint server in a document library (using the deploy to file share publish wizard option) or any file share or web site.
• Launch the form from that location and immediately save a blank form instance and call it "template.xml"
• Also, publish your form template to any libraries where you want people to fill out the form and store documents. After this you will have orphaned copies of the template.
• Next, browse to the first form library and click "Explorer View" in the left column.
• You will see a Forms folder. Double-click that to go there.
• In there you will see the template.xsn
• Drag and drop the template.xml file you created earlier into this folder.
• Right-click the template.xsn and delete it.
• Click "Modify Settings and Columns in the left column
• Click General Settings
• At the bottom there is a template location specified. Rename the file from template.xsn to template.xml. Note you might think you could point directly to the other XSN from here but you can't becuase this link can only be do a file in this library.
• You're Done!
• Repeat for other libraries where you want to use the same template.
Now when you click the Fill out this Form button in the SharePoint library toolbar it will launch the form that you deployed in the central location.
An advanced use of this can also be to have the template.xml file have some prefilled content that you want users to have when launching a new file.
Cheers! Shiraz
Shiraz Cupala
InfoPathDev - Qdabra
Pasted from http://www.infopathdev.com/forums/topic.asp?TOPIC_ID=3040
The typical way to do this is to deploy the form twice, once for each library. However, a few problems arise when you do this:
• If a user tries to open a form from the other library, they will get the form conflict dialog even though the form is supposed to be the same.
• A user who has cached a form from one library, cannot view forms from the other library offline. InfoPath thinks they're different.
• To deploy form updates the form you have to republish to each library separately.
There is a little known feature whereby you can publish the XSN template to one location and then reference it in multiple SharePoint form libraries. The steps to do this are as follows:
• Deploy the XSN to your shared location. It can be on the same SharePoint server in a document library (using the deploy to file share publish wizard option) or any file share or web site.
• Launch the form from that location and immediately save a blank form instance and call it "template.xml"
• Also, publish your form template to any libraries where you want people to fill out the form and store documents. After this you will have orphaned copies of the template.
• Next, browse to the first form library and click "Explorer View" in the left column.
• You will see a Forms folder. Double-click that to go there.
• In there you will see the template.xsn
• Drag and drop the template.xml file you created earlier into this folder.
• Right-click the template.xsn and delete it.
• Click "Modify Settings and Columns in the left column
• Click General Settings
• At the bottom there is a template location specified. Rename the file from template.xsn to template.xml. Note you might think you could point directly to the other XSN from here but you can't becuase this link can only be do a file in this library.
• You're Done!
• Repeat for other libraries where you want to use the same template.
Now when you click the Fill out this Form button in the SharePoint library toolbar it will launch the form that you deployed in the central location.
An advanced use of this can also be to have the template.xml file have some prefilled content that you want users to have when launching a new file.
Cheers! Shiraz
Shiraz Cupala
InfoPathDev - Qdabra
Pasted from http://www.infopathdev.com/forums/topic.asp?TOPIC_ID=3040
Monday, May 7, 2007
Add Fields to SPList Programmatically
The pain of creating lookup fields
The SharePoint UI is great for end users. With very little training they can go off and create new custom lists and through the magic of a Lookup field they can create lookups into other lists and life is grand. For the developer though life is a rotten bag of apples when it comes to Lookup fields.
There are two ways to create new fields in SharePoint sites. You can define them through Xml or create them programatically. With the Xml definitions, it's a matter of copying the CUSTLIST definition (which is just a simple empty list with a single field, Title) to your new definition and add fields. Here's the definition for a new text field:
<Fields>
<Field Name="MyField" DisplayName="My Special Field" Type="Text" />
</Fields>
Simple and easy. The
<Fields>
<Field Name="MyLookupField" DisplayName="My Special Field" Type="Lookup" /></Fields>
The documentation says that the List and ShowField attributes can be used with this type. The List attribute just says it's the internal name of the list (which we would assume that it would be the list we want to lookup values from). The ShowField attribute says it's the field name to display and be used to override the default (Title) and display another field from an external list. There's also another attribute called FieldRef which is the name of another field to which the field refers to, such as for a Lookup field. All in all, it's very confusing but you would think you could do this:
<Fields>
<Field Name="MyLookupField" DisplayName="My Special Field" Type="Lookup" List="MyLookupList" />
</Fields>
And if you don't want the lookup to use the Title Field in MyLookupList then you can use:
<Fields>
<Field Name="MyLookupField" DisplayName="My Special Field" Type="Lookup" List="MyLookupList" FieldRef="LookupFieldName" />
</Fields>
So let's put this to test and have some real data. Let's create two custom lists called Employee and Department. Each entry in the Employee list has a Lookup field that points to the Name field in the Department list. Here's the Lookup field definition in our Employee list:
<Fields>
<Field Name="Department" DisplayName="Department Name" Type="Lookup" List="Department" FieldRef="Name" />
</Fields>
However if you create your lists you'll notice two things. First, if you add an item to your Employee list (the one with the Lookup field in it) you'll see there's no choices available for Department (assuming you added values to that list first). Second, if you try to modify the Lookup field through the UI you get this nasty message:
Guid should contain 32 digits with 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
So what gives? Simple. The List attribute, while it says it's supposed to be Text is but it's not the name of the list. It's the Guid (in the form listed above). The problem is of course that Guids are unique and only known after they're generated. There's nothing in an Xml file (no matter how great the Xml file might be) that can dynamically retrieve the Guid. So Lookup fields, IMHO, can't be used in SCHEMA.XML because they have to be the Guid of the list and that's not known until the list is created first (feel free to jump in and correct me if I'm wrong).
Okay if we can't use SCHEMA.XML to do this, we can write code. Yes, beautiful glorius code. If you have a Lookup field and you retrieve the raw text from it, it looks like this:
42;#Information Services
The 42 refers to (besides the answer to life, the universe, and everything) the ID of the item in whatever list you're looking up. When you retrieve the lookup value you get "42;#Information Services" which you're going to have to transform with a simple little RegEx call if you want to show it to a user.
So now you're thinking if I can retrieve it and get "42;#Information Services" I should set it the same way right? Nope. What you need to do is set the Lookup field with the ID of the value it's looking up in the other list. Internally when you set that, SharePoint will do a join and retrieve the textual representation of the lookup information and save it for you.
Okay, some code to explain all this. This assumes that the site is created with both an Employee and Department list. This snippet will:
• Add a new Lookup field called Department to our Employee List
• Fill in some imaginary Department Names
• Fill in some imaginary Employess that report to various Departments
private void CreateLookup()
{
SPSite site = new SPSite("http://localhost/sites/employee");
SPWeb web = site.OpenWeb();
// Get the Department List from the web for lookups
SPList departmentList = web.Lists["Department"];
// Get the Employee List from the web
SPList employeeList = web.Lists["Employees"];
// Add a new lookup field to the Employee list called Departement
// that will use the Department list for it's values
employeeList.Fields.AddLookup("Department", departmentList.ID, false);
// Create 2 new departments in the Department list for lookups
AddDepartment(departmentList, "Information Services");
AddDepartment(departmentList, "Finance");
// Now create 5 employees with lookups into each Department
AddEmployee(employeeList, "Mickey Mouse", departmentList, "Information Services");
AddEmployee(employeeList, "Goofy", departmentList, "Finance");
AddEmployee(employeeList, "Donald Duck", departmentList, "Information Services");
AddEmployee(employeeList, "Daisy Duck", departmentList, "Information Services");
AddEmployee(employeeList, "Minnie Mouse", departmentList, "Information Services");
// Cleanup and dispose of the web and site
web.Dispose();
site.Dispose();
}
private void AddDepartment(SPList list, string name)
{
SPListItem newDepartmentItem = list.Items.Add();
newDepartmentItem["Title"] = name;
newDepartmentItem.Update();
}
private void AddEmployee(SPList list, string name, SPList deptList, string deptName)
{
SPListItem newEmployeeItem = list.Items.Add();
newEmployeeItem["Title"] = name;
newEmployeeItem["Department"] = FindDepartmentByName(deptList, deptName);
newEmployeeItem.Update();
}
private int FindDepartmentByName(SPList list, string name)
{
int itemId = 0;
SPQuery query = new SPQuery();
query.Query = "
SPListItemCollection items = list.GetItems(query);
if(items.Count == 1)
itemId = items[0].ID;
return itemId;
}
The trick here is that you need to retrieve the ID of the item in the Lookup list based on name, then use that ID and set it in the other list. This is done by a simple call to the GetItems method on the list we're looking for. There are other ways to do this so for example if you have a small list you can load it up into a Hashtable and use the name as the key and the ID as the value. Whatever works for you as the call to the query can be expensive so you wouldn't want to do this for everything but if you just need it for a report or some data loading it's not too bad. Now when you look at your Employee record you'll see it's got a Hyperlink to the Department Name field in the Department list. 15 seconds work for a user in the UI, a couple of hours for you in Visual Studio. Enjoy.
Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!
Published Friday, May 13, 2005 11:40 AM by bsimser
Filed under: SharePoint
source: http://weblogs.asp.net/bsimser/archive/2005/05/13/406734.aspx
MOSS products pricing
All prices reflect estimations for purchases within the United States and are representative of a company purchasing a small number of licenses through Microsoft Volume Licensing.
Note All prices are in U.S. dollars unless otherwise noted. For a customized price estimate, please visit the Microsoft Product Licensing Advisor.
| Servers | Estimated Price |
| Office SharePoint Server 2007 | $4424 |
| Office SharePoint Server 2007 for Search Standard | $8213 |
| Office SharePoint Server 2007 for Search Enterprise | $57,670 |
| Office Forms Server 2007 | $4424 |
| Client Access Licenses | Estimated Price |
| Office SharePoint Server 2007 Standard CAL | $94 |
| Office SharePoint Server 2007 Enterprise CAL1 | $75 |
| Office Forms Server 2007 CAL | $54 |
| Office SharePoint Designer 2007 | $187 |
| Internet Facing Sites | Estimated Price |
| Office SharePoint Server 2007 for Internet sites | $40,943 |
source: <http://office.microsoft.com/en-us/sharepointserver/FX102176831033.aspx>
Subscribe to:
Posts (Atom)