You cannot bind a SObject field (even a picklist one) to a standard apex:selectList component...
<apex:page standardController="Test__c">
<apex:form >
<apex:selectlist multiselect="true" value="{!Test__c.Colours__c}"/>
<apex:inputField value="{!Test__c.Colours__c}"/>
</apex:form>
</apex:page>
The documentation for the apex:select says this about the value attribute.
A merge field that references the controller class variable that is associated with this selectList. For example, if the name of the associated variable in the controller class is myListSelections, use value="{!myListSelections}" to reference the variable. If multiselect is true, the value attribute must be of type String[] or a List of strings. Otherwise, it must be of type String.
A custom field of type multi picklist is exposed as a String (semi colon delimited), I'm not sure how this ever worked in a read or write case for you to be honest. If you switch to use apex:inputField it will work, though i imagine the appearance is not what you want? Your only option is to implement a wrapper class and expose a true String[] array or list as per the requirements of the apex:selectList component above.
Currently there will be no solution without tradeoffs. In most cases I tend to pick approaches which provides good UX and best convenience for the users.
To get something user friendly multiselect picklists doesn't come close. They give me a feeling of the year 2003, more than a few choices end up in scrolling tapestries and selecting+deselecting feels like crap. Fiddeling through 200+ fields will be a task for which the users are not likely to fall in love with you.
From the perspective of the datamodel standard (multiselect) picklists lead often to not normalized structures. Take the countries or languages for instance: it's likely you'll need them on multiple entities and you end up declaring them redundantly again and again with the challenge keeping them in sync. Dataquality r.i.p.
Actually fromthe UI perspective one of the better examples for a nice multiple picklist is the selection of tags here at SFSE:
- supports typing and auto complete
- perfect usage of screen real estate
- comfortable handling
- quite common and intuitive
To get this on a SF layout you need some kind of javascript. There are many to choose from. If you like jquery have a look on this
To keep the datamodel clean and normalized I strongly agree with @DanielHoechst to use custom objects. Expose an editable list page e.g. for language-choices only for admins. Reuse them everywhere. Add and maintain languages on a single place. Alternatively you can use Custom Settings instead. The overall implementation pattern will be roughly the same.
To fetch the choices you could use JS remoting
https://www.salesforce.com/us/developer/docs/pages/Content/pages_js_remoting_example.htm
To store the selected values on the object I would use a text(255) if possible (easier reporting but need for overrun protection plus limits) or you go for a longtext(128000) if necessary. Since the JavaScript is doing the aggregation, there is no need for a trigger.
Now how to get this most conveniently on the layout? And how on edit? This in the end is at the moment the hardest part. To get the custom JS integrated the solution to embed a VF page rules out: a separate save button is clearly not nice.
If you want to be a good citizen you end up in overriding the entire view and edit with vf-pages. apex:detail helps a bit to reuse layouts. But even that's quite radical, it's still best practice. From the admin perspective unfortunately not perfect.
If you're not afraid to get your hands dirty have a look at this
End of javascript sidebar workarounds? - eventually this would provide a solution to wire it nicely into the standard view and edit without VF override - but it likely won't last forever.
For the future all my hope is on Aura Components to get it done right.
Finally reporting is still an issue. But also is with standard multiple picklists. So having a text field with delimiters is not too bad either.
Best Answer
This fixed it... It checks that if the choice exists already on account, you can't add it again on Custom_Object__c.
AND (
(INCLUDES(multi_sel_picklist__c = "Aa")), (Account__r.Aa_field_on_account__c <> "") )