Skip to content

November 6, 2005

Creating a new set of list items from one list into another

Here’s the other bit of code having to do with the pesky created/modified dates.  This is just a function and not a whole program.  It deletes all of the items in a destination list and then copies all of the items from the source list.  The interesting bit is that the created/modified fields hold up to this mechanism.  You can create a new list item that maintains the created/modified dates of the original item.  As with the previous code — this is not intended for direct use.  It’s designed to show you how you might copy the created/modified fields from one list to another.

/// <summary>
/// Copy list data from one list to another
/// </summary>
/// <param name=”spListRef”>The source of the list data</param>
/// <param name=”spListTarget”>The target (destination) of the list data</param>
public static void CopyListData(SPList spListRef, SPList spListTarget)
{
if (spListRef.BaseType == SPBaseType.DocumentLibrary)
{
CopyDocumentData(spListRef, spListTarget);
return;
}
SPListItem spListItemTarget;

// Delete all Items
while (spListTarget.Items.Count > 0)
{
spListTarget.Items.Delete(0);
}

foreach(SPListItem spListItemRef in spListRef.Items)
{
spListItemTarget = spListTarget.Items.Add();
foreach(SPField spFieldRef in spListItemRef.Fields)
{
if (spFieldRef.Type != SPFieldType.Attachments &&
spFieldRef.Type != SPFieldType.Calculated &&
spFieldRef.Type != SPFieldType.Computed &&
spFieldRef.Type != SPFieldType.Counter &&
spFieldRef.Type != SPFieldType.CrossProjectLink &&
spFieldRef.Type != SPFieldType.Error &&
spFieldRef.Type != SPFieldType.File &&
spFieldRef.Type != SPFieldType.Invalid &&
spFieldRef.InternalName != “owshiddenversion” &&
spFieldRef.InternalName != “InstanceID” &&
spFieldRef.InternalName != “Order” &&
spFieldRef.InternalName != “GUID”
)
{
spListItemTarget[spFieldRef.InternalName] = spListItemRef[spFieldRef.InternalName];
}
}

foreach(string attachmentUrl in spListItemRef.Attachments)
{
string fullUrl = string.Format(“Lists/{0}/Attachments/{1}/{2}”, spListRef.Title, spListItemRef.ID,
attachmentUrl);
SPFile srcAttach = spListRef.ParentWeb.GetFile(fullUrl);
spListItemTarget.Attachments.Add(attachmentUrl, srcAttach.OpenBinary());
}
spListItemTarget.Update();
}
}

Creating a file on WSS with the same created/modified date as a file on the file system.

Apparently, I hit a sore spot for the community with my discussion about created and modified fields.  The code that follows is a very rough hack at how you can get a file into WSS while setting the created and modified dates.  I didn’t bother making the code lookup the users’ ID for the site from the name on the file — but that could be done with another half a dozen lines of code or so.  So here’s a command line utility to upload a file to WSS with the same created/modified dates as the original file…  Remember this is a hack… it’s definitely not designed to be used for anything more than realizing how it can be done…

using System;
using System.IO;
using Microsoft.SharePoint;

namespace TESTCREATED
{
/// <summary>
/// Summary description for Class1.
/// </summary>
class Class1
{
/// <summary>
/// The main entry point for the application.
/// </summary>
[STAThread]
static void Main(string[] args)
{
if (args.Length < 3)
{
Console.WriteLine(“TESTCREATED siteUrl ListName FilePath FileName”);
}
string paramSite = args[0];
string paramList = args[1];
string paramPath = args[2];
string paramName = args[3];

SPSite spSite = new SPSite(paramSite);
SPWeb spWeb = spSite.OpenWeb();

SPListCollection spLists = spWeb.Lists;
spLists.IncludeRootFolder = true;
SPList spList = spLists[paramList];

SPFolder rf = spList.RootFolder;

FileInfo fi = new FileInfo(paramPath);
FileStream fs = File.OpenRead(paramPath);
byte[] bytes = new byte[fs.Length];
fs.Read(bytes, 0, (int) fs.Length);
SPUser createdBy = spWeb.Users[0];
SPUser modifiedBy = spWeb.Users[0];
SPFile file = rf.Files.Add(paramName, bytes, createdBy, modifiedBy, fi.CreationTimeUtc, fi.LastWriteTimeUtc);

}
}
}

An update on those pesky fields

Through some email conversations I’ve got a bit more detail on those pesky created and  modified fields.  You can set them when you’re adding a new record — and the values hold.  However, it doesn’t appear that you can set them on an update…  I love wandering around the depths of uncharted (undocumented) SharePoint.

SharePoint: Created By, Created (Date), Modified By, and Modified (Date)

One of the frustrating things about SharePoint 2003 is that the developer documentation is still a bit weak.  The way that we see the impact of this is that well meaning folks end up accidentally saying that something is or isn’t supported.  I’m quite guilty of it myself — although thankfully I’ve not written down any of these errors that I know of yet.

Bil Simser was noodling on the idea of updating the created and modified fields in a list and mentioned that they’re read only. (ListFormWebPart and Tzuanmi SharePoint Designer).  The interesting thing is that I’ve updated these fields in a list.  I did it for some technology POC code I was generating around copying list data from one list to another.  I didn’t even pay attention to the read only field and I got the results I wanted.  I copied the Created By, Created (date), Modified By, and Modified (date) fields.

This wouldn’t be so interesting except Adam Macaulay from CorasWorks and I had a similar discussion on the fields not two weeks ago.  Their Data Migrator tool (a great tool by the way) didn’t preserve Created/Modified dates.  So, I forwarded him along my POC code so hopefully he’ll be able to figure out why they initially had problems with getting the Created/Modified dates to copy from one list to another.

I wonder how many other things about SharePoint that we collectively have wrong.

Recent Posts

Public Speaking