Here's something that mired me down for several hours, so may it be Googled and seen and used by Sharepoint developers:

We're developing a solution right now based on SPS and WSS sites, under several different Site Collections, that involves copying files between sites.

The copying itself is done the same as the MSDN samples show - adding the byte stream to the FileCollection of the destination library - but since we're just passing the bits, the file's metadata isn't automatically copied from one List to the other.

If we're copying Office documents, we have automatic demotion and promotion of metadata properties from the Sharepoint List into the document, which then goes back into the new list. But if we're copying non-Office documents, the metadata is simply lost.

This was bypassed with a simple function after copying that also synchronizes the metadata - but that's where I ran into a strange anomaly having to do with SPFieldLookups - fields that derive their list of possible values from a list in the site.

The format that is saved in the metadata for these kind of fields contains both the identifier of the item in the lookup-list, and the actual string to be displayed, in this format:

“1;#myValue” - with myValue being shown in the list.

Now I want to copy this string from one SPListItem to another - but keep getting strange SPExceptions saying that the data is in an invalid format and suggesting that it is, perhaps, read-only. Preposterous, of course.

More digging and hacking showed that in order to copy the value, we only have to copy the number, not the value.

It DOES make sense, now that I understand it - I only want to pass the ID, after all, not the whole string value - that's why it's a lookup field. I assume that it's stored inside the list for caching, so we won't have to go to the lookup list every time, but still - an explanation, a sample or a meaningful error message would have been appreciated.

No Comments