• Browse Blogs
  • My Blog
  • My Updates

+Tags Get help with tags?

  • View as cloud  | list

+ Similar Entries

photo

Bringing The Power O...

Blog:  Beyond The Ye...
Peter Presnell
Updated 
No RatingsRatings 0     No CommentsComments 0
photo

Adding the "X" Facto...

Blog:  Beyond The Ye...
Peter Presnell
Updated 
No RatingsRatings 0     CommentsComments 2
photo

Tagging Design Eleme...

Blog:  Beyond The Ye...
Peter Presnell
Updated 
No RatingsRatings 0     CommentsComments 1
photo

Add Discussion Threa...

Blog:  Beyond The Ye...
Peter Presnell
Updated 
No RatingsRatings 0     CommentsComments 2
photo

New Video Includes S...

Blog:  Beyond The Ye...
Peter Presnell
Updated 
No RatingsRatings 0     No CommentsComments 0

+ Bookmarks

+ Blog Authors  

Removing Fields No Longer Found On Form

Peter Presnell |   | Tags:  .dominoframework | Comments (5)  |  Visits (509)

It is not uncommon over time for an application to accumulate a lot of fields in documents that are no longer being used.  This will usually occur as a a result of  fields being removed from a form.  In the early stages of development this is especaially common.  The task of cleaning up the database so these fields no longer exist on documents is often a task that is either ignored or considered to be too much of an effort/pain to perform.

 

The latest release of the .Domino Framework provides a RemoveNonFormFields method for the DominoDocumentCollection class.  Running against selecetd documents it build a list of the fields used in the default form assigned to each document and removes document fields if they are not found on the form.  Field names starting with "$" are retained.. The All Document view provides an action button to invoke this method as one of the list of operations that can be perfromed against selecetd documents.

 

Note: This presently only work in situations in which subforms are NOT used and additional fields are not created via events, agents, actions etc.

 

The code is as follows:-

 

 Sub RemoveNonFormFields
  
  Dim Form     As NotesForm    ' Default form used to display document
  Dim FormName  As String      ' Name of form
  Dim FormFields  As Variant      ' List fo fields on form
  Dim Doc     As NotesDocument  ' Document in collection being processed
  Dim HasChanged  As Boolean     ' One or more fields have been removed => document must be saved
Try:
  On Error Goto Catch
  
  Set Doc = iDocumentCollection.GetFirstDocument
  While Not Doc Is Nothing
   
' Identify form used for document
   
   If Doc.HasItem("Form") Then FormName$ = Doc.GetItemValue("Form")(0) Else FormName$ = ""
   If FormName$ <> "" Then
    If Form Is Nothing  Then
     Set Form = DB.GetForm(FormName$)
    Elseif FormName$ <> Form.Aliases(0) Then
     Set Form = DB.GetForm(FormName$)
    End If
    If Not Form Is Nothing Then FormFields = Form.Fields
    
' Remove all fields not found on form
    
    If Not Form Is Nothing Then
     HasChanged = False
     Forall DocField In Doc.Items
      If Left(DocField.Name$,1) <> "$" Then
       If Isnull(Arraygetindex(FormFields,DocField.Name$,5)) Then
        Call Doc.RemoveItem(DocField.Name$)
        HasChanged = True
       End If
      End If
      If HasChanged Then Call Doc.Save(False,False)
     End Forall
    End If
   End If
   
   Set Doc = iDocumentCollection.GetNextDocument(Doc)
  Wend
  Exit Sub
Catch:
  Stop
  ReportError
  Exit Sub
  
 End Sub

No RatingsRatings 0

Comments (5)

photo
1 Andre Guirard commented   Permalink No RatingsRatings 0

Oh. Too bad it's not that easy, but if you use a subform, there could be lots of fields in your documents that aren't on the corresponding form (not to mention, items can be created by back-end code -- even though there's no field for them anywhere, they still should be there).

Also, it looks like you forgot to make an exception for the Form field, which rarely appears on forms but is nonetheless used in many applications.

photo
2 Kevin Pettitt commented   Permalink No RatingsRatings 0

Andre makes good points of course but that doesn't make this capability useless. Closing the subform loophole is fairly easy as is adding other exception fields. You can find examples of how others (including myself) have done this by following the links in this summary I posted on Notes.net in 2006: http://www-10.lotus.com/ldd/nd6forum.nsf/55c38d716d632d9b8525689b005ba1c0/39661025ab476304852571f70051df6b?OpenDocument

Another technique that I used in my own code was to allow the agent to run in "Test" mode. In other words, you can select one or more documents, hit go, say "yes" when asked to run in testing mode, and see all the "ghost" fields printed out to the status bar. The documents remain unaffected, and its a great way to find fields such as the ones created in the back-end as Andre has mentioned. It's fairly straightforward to then add these fields to an exception list and re-run the agent "for real".

Given that running the agent is usually only necessary as part of a signficant design change, having to customize an agent like this is perfectly appropriate.

One additional gotcha you might need to code around is computed subforms. My code only recognizes subforms when directly added to the form, but you could always put some exception logic in the agent for computed subforms you know are there.

photo
3 Theo Heselmans commented   Permalink No RatingsRatings 0

I concur with Kevin and André. Nice code, but pretty dangerous considering the (computed) subform and back-end added data.
Doing a cleanup is pretty easy by making your own agent using:
Field RemoveMe:=@deletefield;
I agree, a generic solution would be better.
What bugs me more is that those pesky fields remain in the field list (UNK?), and are hard to remove.

photo
4 Kevin Pettitt commented   Permalink No RatingsRatings 0

@Theo - Interestingly the reason I wrote my agent (back in the 1999/4.6 timeframe) was to deal with the problem of overloading the UNK/field list with too many fields. To get the fields to go away you have to not only remove them from all the forms, but also from all the documents, and then compact the database (or was it a ctrl-shift compact?). You probably had to do the right kind of compact on all the replicas too.

To this day I try to be very careful about field naming so as to avoid the confusion that can happen with lots of junk fieldnames in the list.

I think it was R5 that brought the "Allow more fields in database" database property (Note to Lotus - should probably rename that property to "application"). Now there is even a form property "Do not add field names to field index" form property which might come in even more handy.

photo
5 Peter Presnell commented   Permalink No RatingsRatings 0

1) Good point about the Form field Kevin, I will add that as an exception.
2) Subforms is something that will be added down the track. Thanks for the links.
3) This was designed more for the applications in which the fields are on a form. With the applications I typically work probably 80% of forms fall into the category where such an agent would work. Because of the risks it is viewed as a devloper tool and not a user tool....

Add a Comment Add a Comment

Previous |  Main  | Next
Skip to main content link. Accesskey S
IBM Lotus Connections Help Tools About