Advertisement

  • How to: Programmatically Create a New FilteredLookup Field A popular question on the FilteredLookup field is how to programmatically create one.

    I've put together the code snippet below to demonstrate one of the ways to go about creating the field from code:

      private static void AddFilteredLookupByXml() {
        try {
          // set target site as appropriate
          using (SPSite site = new SPSite("http://localhost/")) {
            // set target web as appropriate
            using (SPWeb web = site.RootWeb) {
              // the source list, i.e. where data will be retrieved from
              SPList sList = web.GetList("/Lists/Tasks");
              // the target list, i.e. the list that will contain the lookup field
              SPList tList = web.GetList("/Lists/FilteredItems");
     
              // the query to use to filter retrieved data
              string q = "<Where><Eq><FieldRef Name="Status" /><Value " +
                "Type="Text">In Progress</Value></Eq></Where></Query>";
     
              // the CAML xml fragment for the new FilteredLookup field
              string xml = string.Format("<Field ID=\"{0}\" " +
                  "StaticName=\"{1}\" Name=\"{1}\" " +
                  "Type=\"FilteredLookup\" DisplayName=\"My FilteredLookup Tasks\" Required=\"FALSE\" " +
                  "WebId=\"{2}\" List=\"{3}\" ShowField=\"{4}\"/>",
                // the ID (GUID) of the new FilteredLookup field
                  "{b28aa3a5-c186-49e1-b0f6-e9a949ffffff}",
                // the Name and StaticName of the new FilteredLookup field
                  "MyFilteredLookup_Task",
                sList.ParentWeb.ID, // GUID of the source web
                sList.ID, // GUID of the source list
                sList.Fields.GetFieldByInternalName("Title").Id // GUID of the source column
              );
     
              string fn = tList.Fields.AddFieldAsXml(xml); // add new FilteredLookup field as xml
              tList.Update(); // update target list
     
              FilteredLookupField f = ((FilteredLookupField)tList.Fields.GetFieldByInternalName(fn));
              // Don't set both query filter and view filter. ONLY set one or the other
              f.QueryFilterAsString = q; // set query filter
              //f.ListViewFilter = "";
              f.AllowMultipleValues = false; // set allow multiple values
              // set whether query is recursive. This ONLY applies to query filter
              f.IsFilterRecursive = true;
              f.Update(true); // finally update the new FilteredLookup field
            }
          }
        }
        catch (Exception e) {
          e.Source = "AddFilteredLookupByXml";
          throw e;
        }
      }


    The SharePoint FilteredLookup and its source codes are available for download on the codeplex website.

    more
  • SharePoint - Migrating From 32-Bit to 64-Bit Environment In the last few months, there have been lots of talks and conversations over how best to migrate an existing SharePoint implementation from a 32-bit environment to a 64-bit environment. These discussions have also been flamed on by recent announcements by Microsoft that the next version of SharePoint Server (i.e. SharePoint Server 2010) will only be supported on Windows 2008 64-bit Server.

    In an attempt to leverage the benefits of 64-bit computing and pro-actively prepare for the next version of SharePoint technologies, businesses and organisations are looking at ways to migrate their existing SharePoint infrastructure and applications from 32-bit environments to 64-bit environments. This has also been made a rather necessary process as Microsoft has indicated that they would not recommend upgrading from a 32-bit edition of SharePoint Server 2007 directly to SharePoint Server 2010.

    This post sets out necessary steps that should be considered and provided for during the migration planning phase. As part of the migration plan, the following factors and constraints should be considered and catered for:

    • It is recommended that, where possible, a similar topology should exist in the new 64-bit environment as in the existing 32-bit environment. Where the topology consists of one or more farms, you may “mirror” only the primary or live topology. So, as an example, if you have 8 servers in your exiting 32-bit SharePoint farm, it’s recommended that you also look at using 8 servers in your new 64-bit farm, to help keep things simple. However, advanced SharePoint professionals may choose to push these boundaries further.
    • Apply the same service packs and software updates to all servers in both old and new environments.
    • Establish a backup plan, a risk assessment & mitigation plan, and a contingency plan.
    • As some elements of the existing farm will require manual migration, it is recommended that you document all elements of the existing server configuration particularly any custom development or configuration.
    • It is recommended that for each farm in the SharePoint implementation, server migration should be performed in the following order:


    • Perform the migration order one tier at a time; i.e. migrate the database servers first, perform the appropriate tests to ensure the farm is working fine then move to the next tier – the application servers and the perform more relevant tests and then the next tier – WFE and again perform even more relevant tests.

      While a heterogeneous (a mix of 32-bit and 64-bit servers) environment in a server farm is supported by Microsoft, this is not recommended because of the inherent and potential performance issues that may occur. The recommendation is to have a homogeneous environment (servers running on the same architecture – 32-bit or 64-bit), one tier at a time. However, during the migration process it is impossible to maintain a homogeneous environment; thus, you should expect performance issues to occur during the migration process.


    The table below provides a summary of what will be generally affected by the migration from a 32-bit environment to a 64-bit environment.
    Existing Item (32-bit)Comment
    Standard SharePoint ASPX pagesNot Affected
    Standard SharePoint AssembliesNot Affected
    Custom Feature, ElementNot affected if no custom assembly is referenced in it
    Custom WebPart (contained in *.dwp files)Not affected if no custom assembly is referenced in it
    Custom AssemblyThis would need to be recompiled to run on a 64-bit platform; this includes receiver assemblies, web page, code-behinds, web parts contained in assemblies, etc. However, the recompilation isn’t necessary if the initial build option in Visual Studio was set to AnyCPU.
    Custom ApplicationVerify that this can run in a 64-bit environment to ensure compatibility.


    All further custom development for use in the new deployment should be done in a 64-bit development environment or on a 32-bit environment but with the build option set to AnyCPU.


    Most migration tools in the market today can help you migrate contents from previous versions of SharePoint technologies to SharePoint Server 2007 and some also claim to support Windows 2008 64-bit Server but none of them has clearly stated that they support the migration of SharePoint implementation running on a 32-bit environment to a 64-bit environment, and honestly, I do not think they do; at least not as at the time of writing this post.

    Resource(s)
    Advantages of 64-bit hardware and software (Office SharePoint Server 2007)
    Migrate an existing server farm to a 64-bit environment (Office SharePoint Server 2007)
    Determine hardware and software requirements (Windows SharePoint Services)

    more