PreviousNext…

Guh

The latest in a long line of random IBM Lotus Notes error messages.

Well, this error message pretty much sums up the past few weeks:

Recently, I have spent loads of time trouble-shooting, debugging and generally fire-fighting (no, not Andrew’s kind of fire-fighting), and I am heartily sick of it. I haven’t had Domino Designer open this much for a long time. I don’t wish to be mean about Notes, but at the moment I could really do without it. I have a lot of stuff to be getting on with, but sorting out other people’s Notes issues always seem to get in the way. In fact, my skills have rusted to the extent that I naïvely thought that NotesItem.Text could be used with impunity in some code the other day. If you’re still listening (bear with me, it’s a catharsis ;-)) , allow me to explain…

I’ve written a log.nsf parser that grabs mail routing documents from the log and does stuff with them. For some reason, the main field in the logging forms is a single value text one, which is a royal pain in the arse when it comes to distilling some sense from this big ole’ blob of textual data. My solution was to “explode” the contents of this field and go from there. Which is fine, but we weren’t getting as many documents out of this field as expected. Why? Because I used NotesItem.Text to extract the content of the field in the first place. Silly me. Notes likes to truncate this value in a pretty arbitrary way. Looking up NotesItem.Text in Domino Designer help, I found this:

Multiple values in a list are separated by semicolons in the returned string. If an item’s value is large, the returned string may be truncated.

How helpful. Define “large”: are we up against the same limits as with normal strings in Lotusscript (i.e. 32,000 bytes for string literals, 2GB for text content), or what?? Well, in this case, Notes saw fit to truncate the value at 14,682 bytes. Of course.

Anyway, for anyone still reading, extracting the string like so works just fine: NotesDocument.GetItemValue("ITEM NAME HERE")(0). Bah.

Comments

  1. The infamous Lotus Notes 'red box of death'

    The day gets better and better.

    I get the infamous RBoD with code that works just fine in 5.0.11, yet crashes in 6.5.2. The culprit is a call to NotesView.AllEntries.

    Deep joy. What is it with the NotesViewEntry and related classes? This bug has been fixed several times in the 5.x and 6.x code streams, yet seems to kep recurring.

    The regression bug from hell?

    Ben Poole#
  2. Hey, Ben… I did something like that when I worked at Enron. It was a database called LEAP (Log Evaluator And Parser) that took a 5.x log.nsf document and parsed out the lines into a multi-value text field so that I could easily run agents to flag individual lines. In November's e-ProWire: Lotus Developer Tips newsletter, I'll make the ND6 version available which doesn't mess with any of that since the log.nsf documents are already parsed. But if you want an older version of the database, ping me at my email address and I'll dig it up for you (I think!).Duffbert#
  3. Thanks Duffbert, look forward to the ND6.x article. I've narrowed down the cause of this particular issue:

    http://www-1.ibm.com/support/docview.wss?&uid=swg21116483

    Time to get those damned dev servers on something other than 5.0.5…!Ben Poole#
  4. I'm not the only one!

    I got the same Rbod today, while doing some DXL parsing.Ferdy#
  5. … and me too (using LS 'Replace' function with a doc.fieldname as one of my array variants).


    Maybe there's some kind of ND-specific Sunspot event going on today?


    Chris Molloy#
  6. It all becomes clear: so it's YOUR fault Molloy! :-) Ben Poole#

Comments on this post are now closed.

About

I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.

";