0

Have a Lotus Domino database that has been in use for 13 years.

Today a hidden editable field named NumApprovers has started to get garbled values in it on several documents.

enter image description here

The field is updated by lotusscript that counts how many names are in a multi-value field.

The lotusscript has not changed in years - so not sure why the field is suddenly getting the odd values.

Any ideas?

Derek
  • 16,181
  • 3
  • 27
  • 36
  • Was that screen shot taken with the document open? or did you select the document in a view or folder and right click on it to bring up the properties box directly? It does make a difference. Bringing up the properties box from the view shows exactly what is stored in the document on disk, but if you open the document and then bring up the properties box then what you see is the in-memory document after all formulas and field properties specified on the Form have been applied. – Richard Schwartz Nov 08 '12 at 02:43
  • The print screen was taken with the document open in read-only mode. Will check and see if the value shows up differently from a view. – Derek Nov 08 '12 at 03:03
  • Are you using LSI_INFO in any agent? (even unrelated to the field/database). The command has been known to cause that corruption. It should never be used except when requested by support. – Simon O'Doherty Jul 18 '13 at 05:08

2 Answers2

2

Sadly, I can't see the image you posted so it makes it difficult to diagnose.

A few things to ponder... Lotus Notes can give you grief after many years with a 64k error when doing lookups. If you are looking up a list of items from a view from @dblookup or @dbcolumn then it will fall over without notice once you have hit this limit. There are a few other data limits at both 32k or 64k and this is what I suspect you have hit. Take a copy and delete some of the older data to see if that fixes the issue in the copy.

The second thing is database corruption. Very occasionally a database can get corrupted. I would take a copy of the database and run a 'load fixup' - see your admin help or at http://www-12.lotus.com/ldd/doc/domino_notes/7.0/help7_admin.nsf/Links/H_RUNNING_FIXUP_USING_THE_SERVER_STATUS_TAB_7476_STEPS

Finally, it is down to desk checking time. Take a copy of the database and add debug messages through out e.g. 

Print "Info: View returned " + cstr(view.entries) +  entries"

Keep on drilling into the process until you find why the corruption is occurring.

HTH

Ewen
  • 389
  • 4
  • 15
  • 1
    Believe this was database corruption. What appears to have done the trick is to delete the problem fields, and then recreate then. Then did a fixup on the database. So far so good - users not complaining about problem. Thank you for the view.entries tip - not seen that one before. – Derek Nov 12 '12 at 21:31
0

Another thing to think about is that you could cause your users to sign the documents on update, which could help you identify at least which machines/users are causing the corruption. I do not believe your users would start doing so randomly (especially after 13 years), so I'm thinking it's more likely an issue of post-EOL hardware being used which is causing bit errors on writes.

Either way, though, the answer is probably "hardware failure causing corruption", not time-based software failure.

sjcaged
  • 649
  • 6
  • 25