Domino Auto-Trimming Multi Value Fields

It's funny with Domino how I sometimes think I know something about the way it behaves only to find I'm wrong. Whether I was always wrong or the behaviour has changed I'm never quite sure. What I'm about to describe is a case in point.

Here's my long-running assumption: If you have a multi-value field separated by, say, semi-colons and you give it a value of "1;;3;4;5" you end up with five stored items "1":"":"3":"4":"5". It's only if you @Trim the field in its translation that you get the blank item removed and end up with four entries.

It appears this is no longer the case and that you always just get the four items. Has something changed or have I always been wrong?

What was I trying to do? Well, imagine I was trying to maintain a list of names, split in to three multi-value fields — FirstName, MiddleInitial and LastName. Imagine storing the names:

  • Karen L Howlett
  • Jake Howlett
  • Teddy S Edwards

The three fields need to store "Karen":"Jake":"Teddy", "L":"":"S" and "Howlett":"Howlett":"Edwards". If the MiddleInitial field doesn't store the blank entry for my name then it all goes to cock. Names are wrong and @For loops throw errors.

As a fix I used normal text fields and separated values using my own method. I'd be interested to know why I had to though.


    • avatar
    • Lee
    • Wed 28 Jun 2006 06:30 AM

    Hi Jake

    Just a quick test with this shows that if you put a space in as an entry it doesn't trim it so maybe try putting in a translation formula to change a blank into a space and then trim it when you concatenate them so there's not an extra space in the middle. Not the best way but i can't see another way just now.

    • avatar
    • Jake Howlett
    • Wed 28 Jun 2006 06:46 AM

    Hi Lee. Even when I put a space in it trims that as well. What version are you using?

    • avatar
    • Lee
    • Wed 28 Jun 2006 06:49 AM


  1. Jake,

    Blank/null entries have always been removed within domino multivalue arrays. The classic test does not require programming either. Just do to the server configuration document. in the field where tou can block domain/ip addresses for inbound SMTP. enter something with a double semicolono or just do an extra carriage return. you will notice it removes null entries.

    hope this helps

    • avatar
    • Jake Howlett
    • Wed 28 Jun 2006 07:15 AM

    Definitely always Patrick? I'm sure I remember a time when they weren't. I only remember this as at the time I *wanted* them to be removed and thought that an annoyance.

    Is there no way to include blank entries then?

  2. A quick check in 4.6 gave the same result. So, as far as my Notes experience goes, this has always been the normal behaviour. :-)

    But don't wory: Just one week ago I found out that the underscore IS a legal character to start a field name with, when I always thought it wasn't. Things like this keep happening, but not only in Notes, I assume.

    • avatar
    • Steve
    • Wed 28 Jun 2006 08:25 AM

    This goes back as long as I can remember - Can't remember if this happened in v3 but for years I have been adding null values as "~" or "#" instead of "" to keep those null values - especially when there are several multi value fields forming a "table" of corresponding values.

    • avatar
    • Brian
    • Wed 28 Jun 2006 09:16 AM

    It's always trimmed them automatically. That's why we had to put "." or something for the field values in a "dynamic" table.

  3. I'm with Jake-- I thought the default was *not* to trim the blanks from a list...

    • avatar
    • Jake Howlett
    • Wed 28 Jun 2006 01:41 PM

    Thanks Seth. I thought I was going bonkers ;o)

    Whether or not it ever was the way you and I believe, I'm adamant that's the way it *should* be in a world of common sense.

  4. When @trim is used I know this was true in R5. In R6/R6.5/R7 I did @trim within you example and it does show this result. It is possible to have blank lines or null multivales, but that is due to backend (non gui method) to create document(s). I've seen this get trim via the notes client though as well. So I would like see an example app and a specific release / build, Was this behavior client side or web side?

  5. I've actually seen (or think I have) a change in how @Trim works: used to be I could use it to remove either null entries from a list or redundant spaces from a single value... got burned the other day when it suddenly did both, removing redundant spaces from each value in a list where I wanted to remove null list members but keep redundant spaces (don't ask).

    • avatar
    • Anthony
    • Wed 28 Jun 2006 07:44 PM

    Multivalue fields in Notes have behaved like this for as long as I can remember, which is R4 for me.

    This has only effected me in when I wanted to show a table where null entries are present. When this was the case I had two options to preserve the null options in a multivalue field.

    1. The multivalue field that needs to store the null values is not on form. For example if the field is constructed back end and saved to the note then the null value is preserved. The key to this working is to remember that the in memory and backend documents store different values and you can copy the value of the in memory field to another field on the backend document not saving the original field.

    2. Translating the null values to another character so that Notes would register it a valid entry in the list and preserve the order.

    I know both these methods are hacks, but we are talking about Lotus Notes.



    • avatar
    • Richard Shergold
    • Thu 29 Jun 2006 03:34 AM

    Jake, I've been developing in Notes since the R3 days and I'm 100% certain that @Trim has always removed blank entries from the list.

  6. Hm. Let me try...

    "Microsoft;Sun" ".NET;Java"

    Now if I make .NET a null... hm. Everything still looks the same.


    Too vague?

    • avatar
    • Rod Stauffer
    • Thu 29 Jun 2006 04:28 PM

    Wait a sec everybody. Yeah, @Trim will trim out the blanks. It's always been that way, and Jake knows that. Problem is, the nulls are getting trimmed without using @Trim.

    Well, I think the distinction is that computed fields and editable fields do things kinda differently. In a computed field, the nulls will remain (unless @Trim is used). In an editable field, the nulls are automatically trimmed (apparently it's assumed that consecutive separators equate to user input error or something)...

    So, what to do...at a high level, here's one approach:

    If all the values are on a single document, create a table or grid mechanism. Computed fields for First, Middle, and Last names. An "Add" button to bring up a dialog box or something to add a "row". A "Delete" button to bring up a dialog in which the row to delete can be selected. An edit button (first dialog is to select the row, second dialog to actually edit that row).

    That removes the auto-trim behavior of editable fields from your form. The null values will remain in the computed fields.

    Hope that helps.


    Side note: "Trim" in LotusScript is the one that removes only whitespace. They added "FullTrim" to duplicate the behavior of @Trim.

    • avatar
    • Rod Stauffer
    • Thu 29 Jun 2006 04:33 PM

    To be pedantic, I shouldn't have used the term "nulls"... Empty, or Blank would have been more appropriate. Still, you get the idea.


    • avatar
    • Richard Shergold
    • Fri 30 Jun 2006 01:11 AM

    Rod - you're right. I misread the post, I thought Jake was questioning the @Trim functionality.

    • avatar
    • Martin
    • Fri 30 Jun 2006 11:45 AM

    Uff, thank you Rod, I started to be afraid about one of our application, where we use space for empty values and it's working - because it is computed fields.

  7. its really good can u send me this dattabase

Your Comments


About This Page

Written by Jake Howlett on Wed 28 Jun 2006

Share This Page

# ( ) '


The most recent comments added:

Skip to the comments or add your own.

You can subscribe to an individual RSS feed of comments on this entry.

Let's Get Social

About This Website

CodeStore is all about web development. Concentrating on Lotus Domino, ASP.NET, Flex, SharePoint and all things internet.

Your host is Jake Howlett who runs his own web development company called Rockall Design and is always on the lookout for new and interesting work to do.

You can find me on Twitter and on Linked In.

Read more about this site »

More Content