Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I have a custom SharePoint 2010 SPfield of type SPFieldMultiColumn. The data in this column is stored in a delimited string, which is parsed and rendered in a readable format in most areas (list view, 'view properties' etc). The raw data looks like this (wording changed):

;#0;#LABEL1;#True;#GUID;#DESCRIPTION_OF_LABEL;#;#1;#LABEL2;#True;#GUID;#DESCRIPTION_OF_LABEL2;# ...

and so on. The descriptions are pretty long, making this string hundreds of characters long, and really ugly when not parsed out and rendered. The issue with this is that in certain parts of the system, we cannot control the rendering of the field. The most common issue we see is in datasheet view, where the raw data is displayed and just looks terrible, and makes datasheet nearly unusable for users. The data also shows up in alert emails and search results.

I was tasked with making this 'prettier' and my solution was to add a secondary, 'display' column, and to hide the 'data' column. When an item is updated or added, I have event receivers which transform and move the data into the display field, which looks nice in datasheet view and so on.

This all works great, except for the fact that it requires 2 Update() calls on each item that gets this metadata. One when the 'data' field is populated, and another when the event receiver copies the data into the display.

Our production (and QAS, but not test or development) farms utilize Remote Blob Storage (RBS), and our operations team has found that whenever this column (or I guess any column) is updated on an office document (doc, docx, etc) it causes a new blob in the file system. So as the solution is today, a new file uploaded will generate 2 blobs (one for the upload, one for the application of this metadata). With this new eventreceiver, we will now generate 3 blobs, which is unnacceptable to our operations team (we don't have 50% more disk space to support this).

'Fixing' RBS is out of the question - so I need to somehow update both of these columns at once, rather than updating one, which fires an event receiver to update the other.

Is there any way to update 2 custom SPFields with 1 call to Update()?

TL;DR: Custom solution with 2 custom SPFields - one updated through the 'edit' form, the other through an event receiver (second is completely reliant on the first for it's data). How can I update both without the use of an event receiver (with only one Update() call?)

share|improve this question

2 Answers 2

up vote 2 down vote accepted

It sounds like you're using the ItemUpdated event. If you used ItemUpdating I believe you could modify the AfterProperties instead of performing a second update.

This may be of use to you: NBSP: Event Receivers

share|improve this answer
    
Thanks. My first attempt when implementing this was to try using ItemUpdating, but I seem to recall not being able to get it to work (this was ~6 months ago now, our test cycles are slow :) ). I will re-visit this and see if I can't get it to work with an ItemUpdating event receiver. –  sean Dec 11 '12 at 18:31
    
Alright, I have my code being executed in ItemUpdating, and I'm grabbing the AfterProperties value from the data column, transforming it, and attempting to do this: properties.AfterProperties[DISPLAY_COLUMN_INTERNALNAME] = displayString; without calling any Update() method. This doesn't throw any errors, but also doesn't update the column. When I loop through all of the entries in AfterProperties, I'm not seeing my display column. Does AfterProperties only include changed fields? –  sean Dec 12 '12 at 18:34
    
I'm not sure. Have you tried using AfterProperties.Add? –  Stuart Pegg Dec 12 '12 at 20:12
1  
This was the answer. Thank you for the suggestion! It turns out that the AfterProperties hash uses DISPLAY NAMES (why!?) to update the sharepoint fields. You can add anything to this hash, but unless it matches the display name of a field, it won't do anything. The problem was that my second 'display' column has the same Display Name as the first 'data' column. That's why I wasn't seeing results. I changed the display name, and now I'm able to update both fields with the itemadding event receiver, and only generating 2 BLOBs in RBS, not 3. Thank you! –  sean Dec 14 '12 at 17:46
    
@sean: No worries :) –  Stuart Pegg Dec 14 '12 at 20:43

When you create a Lookup column, you can choose to show additional columns from your lookup list.

It looks like what you would want here is a list with your Label/Description, and then a lookup column to the Label column, and have the description as an additional field. I don't know if it would be perfectly clean in Data Sheet View though, but it would be an improvement.

Another potential solution to this sort of problem is a Calculated column, but from what I see of your scenario it doesn't fit.

share|improve this answer
    
Funny you say that, as the implementation in one of our previous sharepoint environments was to do just that. There was a list in each site collection which contained the labels and their descriptions, and a lookup field on the libraries that needed the labels. Unfortunately with our upgrade to 2010 (not an in-place upgrade - we stood up the farm and migrated data from many systems across the company into it), we were tasked with 'enhancing' this metadata column. We now have really complicated form logic and additional fields all jammed into this one column. –  sean Dec 11 '12 at 18:33
    
Continuing from above. A lookup column would not work due to our complicated requirements. We need to keep track of which label(s) are selected, and if the label has extra data (like a free text field or an additional choice if you pick certain ones), we need to track that as well. –  sean Dec 11 '12 at 18:44

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.