This content has been marked as final. Show 7 replies
Thanks Jiri for your response.
Actually, we have a meta-data that is of Multi-Select type and there are many values in the drop down and for some reason we have to select all the values from the drop down that's why size of field getting increased with 4K limit.
Also here we can not attach a file for above mentioned scenario.
In UCM, can we make a meta-data field of type CLOB sothat it can store all the possible values?
Or is there any other way to implement this of requirement?
Edited by: 879506 on Dec 9, 2012 9:41 AM
In UCM, can we make a meta-data field of type CLOB sothat it can store all the possible values?OOTB CLOB cannot be used for metadata fields. It might be quite challenging to do it even as a customization.
However, you can simply create an attached file, have it indexed, searchable and then, from this file navigate to the master item.
meta-data that is of Multi-Select typeI also wonder why you want to implement a multi-select via a memo over 4K. a) do you store it as a comma-separated list in the field (I'd expect you'd have a lookup table with values and another one with links) b) do you really have that many selected values that you need length over 4K? (and don't you have problems with displaying the drop-down?)
Actually, we have a meta-data that is of Multi-Select type and there are many values in the drop down and for some reason we have to select all the values from the drop down that's why size of field getting increased with 4K limit.Why not simply add another entry to the option list like "All values apply"? Select that one when
we have to select all the values.
jiri.machotka wrote:I also wonder why you want to implement a multi-select via a memo over 4K. a) do you store it as a comma-separated list in the field (I'd expect you'd have a lookup table with values and another one with links) b) do you really have that many selected values that you need length over 4K? (and don't you have problems with displaying the drop-down?)Exactly. If you are using keys to store the values, and displaying a friendly name to the user as the option, just how long is this option list that 4000 characters isn't long enough? I'd think there would be usability issues at the very least.
Thanks for your responses.
Let me explain the scenario again in detail:
1. we have three meta-data fileds xProductCategory,xProductFamily and xProducts
2. These fields are related with DCL feature and corresponding values are being stored in corresponding custom Views
3. xProducFamily is dependent of xProductCategory and xProduct is dependent on xProductFamily
4. currently, there are around 250 Product values and average name of Product can be of 25 Char, so if we are selecting all product values for some Contents then Product Values are being stored in DocMeta table as comma separated values with one space, so total characters are being very high than 4K Char.
5. Currently view that is storing the Product values, stores "Name" column instead of ID(like 1,2,3....)
6. And our Content Server is integrated with Oracle WebSenter Portal, where logic has written to retrieve the contents based on "Product Name" instead of "Product ID" and already we are in UAT phase.Currently we are not in situation to revert the changes from Product Name to Product ID.
7. Also if we are storing the values on the basis of Product ID, then again the issue may arise in Future, if the number of Products increased.
Hoping the issue explanation is clear now and waiting for some possible solution for increasing the length of memo field.
Thanks in Advance !!
Yes, we can use the option as "All values apply" value in the drop but there there are some other scenarios as mentioned below:
1. There are total 250 Product values in the drop down
2. If user wants to tag only 225 Products, then again it crosses the limit of 4K char. So, in this case the value "All values apply" will not work.
Do you have any other possible solutions? Please let me know
Thanks a lot for help in Advance !!
The obvious and best solution is to redesign the stored values to be short, unique keys. Starting with the number 1, and working up to the number 225, adding a space and a comma between each entry is only 1,015 total characters, which is WELL beneath the 4k limit.
Jiri also mentioned earlier about creating an alternate file with this extended data. That would work as well.
Some people would say that adding an additional field to store the overflow data would be an option, but it is more of a maintenance headache.
You say that a user could enter 225 values. Realistically, how many times would that scenario happen? 50% of the time? 25%? 10%? 2%? I'm not feeling that this is a common occurrence, otherwise it would have surfaced in the design phase of the project instead of the QA phase. If it's low occurrence, I'd require the user to put the values in a second document and check it in as the alternate