Error: "Cannot Store Document: Database Has too Many Unique Field Names" Attempting to Import Document


 Product:
 Import Utility for Lotus Notes / Domino > Troubleshooting > Version All

 Platform(s):
 All

 Edition(s):
 All

 Doc Number:
 1000004
Published 13-Nov-2010

 Problem

When you attempt to import documents the following error message occurs:

"Cannot store document - database has too many unique fields names. Please set the 'Allow more fields in database' option or ask your administrator to compact the database."

 Solution

The 'Allow more fields in database' property for the database you are attempting to import data into should be enabled as per the following image:



After enabling the above property the database should be compacted. Once done try running the import again.

If you continue to get this error even though the "Allow More Fields in Database" option has been enabled and the database has been compacted you can try the following:
  • Delete Obsolete Fields - If you have field names that are no longer needed, delete them from all Forms and documents in the target import database. For example, to delete an obsolete field called LastYear from existing documents, your agent would be "FIELD LastYear := @DeleteField".
  • Use Shared Fields or Same Name Fields - In situations where different fields are being used on multiple forms to accomplish the same task, using one shared field would limit the number of unique fields, thereby bringing the UNK (Unique Key Table) size down. For example, if you had a "From" field on one form and an "Author" field on the other, but they both calculated @Username, it would be best to use one shared field. Alternately, you could use the same (exact) field name and data type on multiple forms to limit the UNK. So in the prior example, instead of using "From" and "Author", you would use "From" on both forms to calculate @Username.
  • Shorten Field Names - Since the UNK uses the actual field lengths of every field in your database, reducing the number of characters for a field, will limit the size of the UNK. For example, instead of using "FiscalYearGrowthAllocationForecast", use "FYGAFrcast".
  • Split Up the Design into Multiple Dbs - If the target import database uses so many field names that it hits the UNK limit, it may be time to split up the design into multiple databases. It would be best to split the design based on functionality to lower the total number of fields in a particular database. For example, if you have documents for Inventory and documents for Orders, your inventory documents may have fields for "NumberAvailable", "WareHouseLocation", "Supplier", whereas your order form may have "CustomerName", "ShipTo", etc.. By splitting up these documents, and the forms related to them, into separate databases, you will reduce the overall field names contained in one database, thereby reducing the UNK Table size.
  • Re-add and Delete Field - If an obsolete field is no longer in use on the form, but is listed under design properties of the form, it will be included in the UNK. To try to delete it, edit the form, re-add the field with the same spelling, and save the form. Now delete the field by placing your cursor to the right of the field and pressing the BACKSPACE key. Notes will prompt you to delete the field. Select Yes. If this does not work, you may need to create a new form by copy/pasting fields from the old form to a new form, and then delete the old form.
  • COMPACT the Database with no Full Text Index Built - Compacting the database rebuilds the UNK Table. However, if a database is full text indexed, the UNK is preserved. Prior to deleting the UNK, the compact task scans the database header to see if the full text index bit is set. This can be checked by opening the database with NotesPeek, looking at the "Database Information" and checking to see if the "Options" on the right contains the text, "FTIndex". If it does, then the original UNK will be preserved. If the database is full text indexed, go into Database Properties (File, Database, Properties), delete the full text index (select the Full Text tab and select Delete Index button), then compact the database. After compaction, the full text index can be recreated.
    If under Database Properties, it does not appear that the database is full text indexed, but the FTIndex flag is visible through NotesPeek, create a full text index and then delete the index. This will turn off the FTIndex flag, and successfully compress the UNK, during Compact, to only fields present in the database. The compact process deletes the UNK, and scans all notes in the database for the existence of unique fields. If the field exists anywhere (design element or live document), it will be added to the newly built UNK. You should compact from the beginning to ensure your UNK Table is a representation of all the current fields being used. You should compact the database after performing any of the previous steps of deleting obsolete fields, using shared fields, shortening names, splitting up design, etc..

Notes:
  • Copy-style compaction must be used in order to rebuild the UNK table.
    From the Domino Server console type: load compact database.nsf -c.
    From a Notes Client (example is for Windows operating systems) execute from the Notes directory: ncompact \datapath\database.nsf -c
  • If running Compact against the target import database generates the "Max number for fields..." error, first make a new replica of the database before running Compact against it.
  • In certain cases, unused field names will remain in the design document; hence, COMPACT will not remove them from the UNK table. This happens when the deleted field is of type Number or Time.



© 2010 AGE Computer Consultancy. All rights reserved.
Material may not be reproduced or distributed in any form without permission.