JoelBlogs - Joel Jeffery's Microsoft 365 Blog

Microsoft 365, SharePoint, Teams and Office 365 Architecture, Development, Administration and Training

  • Home
    • Sitemap
  • Articles
    • #SPThingADay
    • SharePoint Online
      • SharePoint Online – Drag and Drop and Large File Uploads
    • SharePoint 2016
    • SharePoint 2013
      • Content Database Changes to the AllUserData Table
    • SharePoint 2010
      • Administration
        • Disable CRL Checking
        • Excel 2010 & PowerPivot
        • Limits & Thresholds
        • PeoplePicker AD Errors
        • Recycle Bin Behaviour
        • Renaming a Server
        • Service Pack 1
        • Unattended Installs
        • Uninstall All SharePoint 2010 Solutions via PowerShell
        • User Alert Management
        • Virtualised SharePoint
        • Visio Stencils for Administrators
      • Development
        • Audience Membership Workflow Activity
        • Base Types, Lists & Content Types
        • BCS & Offline Sync
        • Debugger Skipping Lines
        • Development Laptop Spec
        • Enabling JavaScript IntelliSense
        • Event Receivers & Deployment Jobs
        • FavIcons & SPUrl
        • Google Maps Sandbox Web Part
        • Group By Content Type for List Views
        • Locale Stapler / Master or Default Locale
        • Removing Default Editor Parts
        • Sandbox Embedding Resources
        • Solution Sandbox Introduction
        • SPPersistedObject
        • Restoring Deleted SPSites in SP1
        • SPWebConfigModification 1
        • SPWebConfigModification 2
        • STSADM copyappbincontent vs. Install-SPApplicationContent
        • Workflows for Beginners
        • Workflow InitiationData Seralizer
    • SharePoint 2007
      • Alternate Access Mappings
      • Excel Services
      • Excel Services UDFs & Excel Client 2007
      • Experiences from the Field
      • InfoPath & Forms Server
      • Kerberos & SSRS
      • Records Management
      • Web Application Service
      • WSS vs MOSS
  • Training
    • SharePoint Admin Links
  • Downloads
    • Summary Slides for PowerPoint
    • CodePlex Projects
      • Audience Membership Workflow Activity
      • Google Maps Sandbox Web Part
      • Group By Content Type in List Views
      • Locale Stapler / Master or Default Locale
      • SharePoint Outlook Connector
  • Hire Me!
    • MCP Transcript
    • Résumé/CV

SharePoint 2007 Experiences from the Field

October 22, 2008 by Joel Jeffery

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.

Microsoft System Center Data Protection ManagerHere’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.

Filed Under: SharePoint Tagged With: Backup, DBCC, DPM, Microsoft, MOSS, SharePoint, SharePoint Administration, SHRINKFILE, SQL Server, System Center, WSS

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

October 22, 2008 by Joel Jeffery

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

InfoPath 2007InfoPath. 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.

InfoPath Form in a Browser - Click to zoom!InfoPath Form in a Office Client - Click to zoom!

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.]

Xsn file opened as a Cab - Click to zoom!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.

InfoPath Forms development environments - Click to zoom!

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!

Filed Under: SharePoint Tagged With: InfoPath, Microsoft, MOSS, SharePoint Architecture, VSTA, VSTO, XSN

« Previous Page
Next Page »

Joel is a full-stack cloud architect who codes. He is a Microsoft Certified SharePoint Online, SharePoint Server and Azure specialist and Microsoft Certified Trainer.
He has over 20 years' experience with SharePoint and the Microsoft .NET Framework.
He's also co-founder of Microsoft Gold Partner JFDI Consulting Ltd. Read More…

Recent Posts

  • Microsoft Flow Tip #1 – Word Templates and Hiding Empty Repeating Sections
  • SharePoint PowerShell Tip #1 – Select-Object and FieldValues
  • Popular Misconceptions – Microsoft Teams relationship with SharePoint
  • Course: Microsoft 365 Certified Teamwork Administrator
  • Audience Targeted Searches in Modern SharePoint Online
MCT 2020-2021
Microsoft Teamwork Administrator Associate
Joel's Acclaim Profile
Joel's Microsoft Profile

Tags

Administration Architecture Certification Cloud Development freetraining Information Architecture intranets MCP Microsoft Microsoft Architecture Microsoft Azure microsoftsharepoint migration Mobile Development MOSS Office 365 office365 Office 365 Permissions PowerShell SaaS SharePoint SharePoint 2010 SharePoint 2010 Training SharePoint 2013 SharePoint Administration SharePoint Administrator SharePoint Architecture SharePoint Developer SharePoint Development sharepointia SharePoint Online sharepointonline SharePoint Search SharePoint Training SharePoint Videos Silverlight SOA SPThingADay TechEd 2007 Training Videos Windows Phone 7 WSS

Copyright © 2022 Joel Jeffery, SharePoint Architect