MOSS – Page 2 – JoelBlogs – Joel Jeffery's Microsoft 365 Blog

My good friend and colleague Cédric Oster has an excellent blog on his experiences with SharePoint 2007, InfoPath 2007 and more. Cédric is a SharePoint consultant of quite some standing.

You can read Cédric’s SharePoint Blog for his latest writing. I’ve just read his piece on SharePoint database growth rates, and how to deal with them. Very sound advice – Cédric writes:

“To free up space manually: after a full backup you can shrink and truncate the log file to any size you need by doing the following:

Open SQL Server Management Studio

Select the database you want to shrink the log file (e.g. MOSS_Intranet_Content)

Click the “New Query” button

and run the following command:
dbcc shrinkfile (<LOGICAL LOG FILE NAME>,<SIZE IN MB>,truncateonly)

for example: dbcc shrinkfile (MOSS_Intranet_Content,2,truncateonly)

This applies to the Content Databases but also the Configuration and Search Databases.”

I should point out that this principle also applies to SQL Server development in general. If you’re developing using SQL Server, very often backup, restore and maintenance can be all too easily forgotten. The best side effect of which is that you end up with an enormous log file, or performance would eventually be degraded. The worst side effect could be that you might not have a database backup and maintenance schedule, which could put your data at risk.

Here’s what MSDN has to say about DBCC SHRINKFILE. Similarly, I should point you at Joel Oleson’s Blog – another noteworthy SharePoint blogger. He has an excellent article on Best Practice for SharePoint Backups.

I would side with Joel here, not just because we share a name, but because I, too, really rate Microsoft System Center Data Protection Manager as the best mechanism for WSS and MOSS backups. Here’s an informative webcast from Microsoft on backing up MOSS with DPM. This may well become a topic for a future blog entry for me.

Here is the second in a series of impromptu hints and pointers for Microsoft Office SharePoint Server 2007.

InfoPath. Have you used it? You’re not still using Microsoft Word and form fields, are you? In addition to being a great alternative to locked Word documents for departmental form filling, InfoPath is a great development platform.

You can use InfoPath forms for a number of tasks: capturing form data and saving it as a document (of course); uploading into SharePoint to start a workflow; using custom InfoPath forms to allow admins to configure reusable workflows; rendering in a browser via ASP.NET.

Which brings us to:

Popular Misconception #1 – “InfoPath forms need InfoPath installed on the desktop. We don’t have control over what’s installed on our users’ PCs, so we can’t use InfoPath.”

Admittedly, the user experience is better when InfoPath forms are opened in InfoPath Client 2007, but you can publish a form with a high degree of fidelity either through a browser-enabled SharePoint Document Library, or on a custom ASP.NET page in MOSS using the <XmlFormView /> control.

[Gotcha: the Document Library containing the browser-enabled form and your custom ASP.NET page have to live within the same Site Collection! Here is a great article on the MSDN site detailing the steps to use the XmlFormView control.]

Popular Misconception #2 – “I can publish an InfoPath form as browser-enabled, and it will look and feel just like InfoPath Client.”

Well, no. It’s good, but it’s not *that* good. The rendering is pretty faithful, but there are some features that are just incompatible. There are others features that behave quite differently in the browser-enabled version.

The images below show how the a simple for can render in both a browser and the Office Client, left and right respectively.

Some field types available in the Office Client just aren’t available in (this release) of the browser-enabled forms. For instance, instead of Combo Box fields, you have to use List Box fields. Instead of Rich Text fields, you have to use multi-line text boxes. It can’t be long before this gap is closed. With the current crop of AJAX frameworks (Microsoft, ExtJS, others) these controls should be able to be represented. Maybe next version.

There are other differences too: browser-enabled forms with complex logic, multiple data sources, business logic events and a raft of other conditions can cause your form to require a postback during editing. This is all handled automatically, but it can still cause a downgraded user experience, and increased server load.

[Gotcha: You can’t publish InfoPath 2003 forms as a browser-enabled, Office Forms Server form! InfoPath 2003 uses a COM APIs, whereas InfoPath 2007 and Office Forms Server 2007 use .NET APIs.]

Popular Misconception #3 – “InfoPath forms are just Xml. I can create them in Notepad if I wanted to.”

“Close,” as Roy Walker would say, “but not right.” The principle is that InfoPath forms are defined as Xml. When you create one and save it, you get an .xsn file. As with much in the world of WSS and MOSS, these files are re-purposed and re-named .cab files. Here’s something you can do: create a simple InfoPath form, save it as an .xsn file and rename it – changing the extension to .cab.

When you double click it, Windows Explorer should open up the .cab and show you the contents.

Typically, an .xsn file you create will contain by default a few different Xml files:

File Type	Purpose
manifest.xsf	The core InfoPath form definition file. Defines the fields, repeating blocks and controls used in your form.
myschema.xsd	Xml Schema Definition file that defines the shape of your Xml data. In the case of InfoPath forms that consume web services, this is generated from the WSDL.
sampledata.xml	Specifies what the default values should be for each of the fields on your form.
template.xml	The Xml document that InfoPath will populate with data and submit.
view1.xsl	An Xslt file describing how to render the form. Incidentally, forms are rendered, even in the InfoPath Client, as Html.

It will also contain any media files that you embed in your form, such as images and logos, and any further view*.xsl files specifying additional views on your form. If you have .NET business logic in your form, the resulting .NET assemblies will also be included in the archive.

Popular Misconception #4 – “I can only create InfoPath forms in the designer of Office InfoPath Client.”

Visual Studio Tools for Office 2005 and Visual Studio 2008 form a great environment for developing InfoPath forms. This gives us two choices:

A combination of InfoPath Client 2007 designer to design the form and Visual Studio Tools for Applications (VSTA) to create .NET business logic
Visual Studio 2005/8 with Visual Studio Tools for
Office (VSTO)

The picture below shows the a similar form being designed in both environments.

There are pros and cons with each method.

Visual Studio 2005/8 requires a license! If you aren’t developing other .NET projects, VSTA and InfoPath Client provide a robust and flexible development experience.
Visual Studio 2005/8 with VSTO uses its own rendering engine in the designer – there are some discrepancies between what gets rendered in each. The InfoPath Client offers the more faithful reproduction during design.
The premium development environment is still Visual Studio 2005/8. VSTO and Visual Studio integration is very close indeed. With InfoPath Client and VSTA you are using two separate applications.

For the hardened developer, Visual Studio 2005/8 will be the better of the two choices.

Here you can read Microsoft’s Andy Whitechapel discussing the differences between VSTA and VSTO.

Happy coding!

SharePoint 2007 Experiences from the Field

WSS 3.0 and MOSS 2007 tips #2 – Popular Misconceptions – Microsoft InfoPath 2007 and Office Forms Server 2007