Was geht noch:
What To Do Once UNK Limit Is Reached
Delete Obsolete Fields - If you have field names that are no longer needed, delete them from all Forms and documents in the 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 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 one 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, we scan 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..
Note: Under Domino 4.6x the Compact task does not remove unused fields as expected. For more information see the document, "Compact Is Not Removing Unused Fields From a Database" (#179972 ).
Note: In R5, copy-style compaction must be specified in order to rebuild the UNK table. Example: >compact database.nsf -C
Note: If running Compact against the problem database generates the "Max number for fields..." error, first make a new replica of the database before running Compact against it.
Note: 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. Lotus Quality Engineering is aware of this issue. (SPR# RMAS3ZMK5B).
Note: An enhancement request for the removal of the Full-Text Index limitation has been submitted to Lotus Quality Engineering (SPR# RMAS42JVZ9).
Note: There is a utility available from Notes Support Services which shows the UNK table of a database; this utility will be sent out on an as needed basis. Even if the table size returned by the utility indicates a value below 64k, overhead during processing of the table adds to its size and can cause the noted error. For example, if a table size is indicated as 60k it could still surpass the 64k once the overhead is added. There are no specifics on the additional size that overhead will add.
Note: There is a utility available which shows the UNK table of a database; please refer to the online resource document, "Tool to Show the UNK Table Size for a Notes Database" (#2579) for information on this utility. Even if the table size returned by the utility indicates a value below 64k, overhead during processing of the table adds to its size and can cause the noted error. For example, if a table size is indicated as 60k it could still surpass the 64k once the overhead is added. There are no specifics on the additional size that overhead will add. Please note that the utility is provided "as is", unsupported; any problems with the tool should not be reported back to Lotus since it is unsupported.
* In Notes Support, some analysis was done on customer applications, and it was found that with an average field length of 11, the UNK could store 3,200 fields. A conservative gauge would be an average field length of 10, and 3,000 fields, should bring you well within the UNK limit.
Supporting Information:
Important Note:
The UNK Table is used at a core level of Notes. Increasing this limit requires major revisions to the product. The customer issues surrounding the UNK limit were reported to Lotus Development and Quality Engineering (SPR# RSAR39ELHZ), and have been addressed in Notes 5.0 Client and Domino 5.0 Designer, with some caveats.
In R4, the UNK table size is directly affected by the length of individual field names. This is conservatively estimated at 3,000 fields averaging 10 characters in size. In R5, this limit has been increased to 22,893 fields (approximately 7 times the number of entries available in R4). There is an option available in R5 that allows additional fields to exist in an R5 database. However, there are some caveats. First we will cover how to enable this option, and then discuss caveats.
To Enable:
There is now an option on the Advanced tab in the Database InfoBox called "Allow more fields in database". Selecting this option enables functionality called Large UNK Tables. In order to take advantage of Large UNK Tables, the database must be converted to the R5 format by compacting it on an R5 Server, or compacting it locally on an R5 Client. Once it is in the R5 format, then it will have the same access limitation that existed between R3 and R4. The limitation is, R4 clients will be able to access the database only on a R5 server and not locally unless a new replica is pulled down. This is because R4 clients cannot understand the R5 database format unless accessing it through a R5 server. Attempting to add fields to the database without compacting the database to convert it into the R5 format, will still result in errors regarding the 64k UNK limit. So, in summary, the 64k UNK limit is removed in the new R5 database format.
Caveats:
Not all areas of R5 have been coded to support the Large UNK Tables. If you turn on the "Allow more fields in database" property, once your UNK Table gets large enough and starts using the Large UNK Tables, then areas of the product that cannot handle large UNKs will not work. Currently this includes the following:
- Full Text Indexing query by field
- Query by Form
Thema: Fehlermeldung: Die Datenbank enthält zu viele eindeutige Feldnamen (Gelesen 3680 mal)