Each database that is created contains properties unique to that database. The Database Properties settings enable you to customize the behavior and performance of the database. They also provide a window into statistics about the database and who is accessing the database, as well as the size and general health of the database.
The Basics tab contains four sections. The first section displays the initial information about the database that was entered when the database was first created and additional information that you can change, as indicated in Figure 2.12.
Figure 2.12. The title and type of the database can be modified from the Basics tab of the Database properties dialog box.
When a database is first created, it is given a filename and a title, both of which are shown in the Basics tab. The title can be changed here, but the filename can't because that is part of the file system, not Notes. The database type can also be set here. Various types of databases can be created, as shown in Table 2.3.
Table 2.3. Database Types
|Standard||This is the database type for most applications and the default for all new databases that are created.|
|Library||The Database Library template is of the library database type. A database library lists published databases for users to review and add to their workspace. You can publish databases to the library by opening the database that you want to publish and then choosing File, Database, Publish from the menu.|
|Personal journal||This database type can be used by a mail client or a full Notes client, and it is intended for personal use.|
|Domino directory||The Domino directory database type is reserved for the various types of address book templates available in Notes and Domino 6.|
|Directory catalog||The directory catalog is the same as a light address book, which is an address book with fewer design elements and a smaller footprint on a local drive. Directory catalogs are most often used in large organizations with large Domino directories to keep the file size and access speeds of the directory smaller and faster.|
|Portfolio||The portfolio database template provides a single point of entry into often-used databases for a user . The welcome page database, Bookmark.nsf, is a portfolio database.|
|IMAP server proxy||This defines to the server the database type for an IMAP server proxy.|
|News server proxy||This defines to the server the database type for an NNTP proxy server.|
|Subscriptions||This database type provides a way to log subscriptions to other databases. The Headlines.nsf database is an example. Subscription databases cannot be replicated.|
|Multi DB search||This database lets you search multiple Domino databases on a site.|
|Mailfile||This refers to a standard mail database that sends and receives electronic mail.|
|Mailbox||This holds and routes mail (mail.box, for example).|
The Settings section of the Basics tab provides access to the archive settings, encryption settings, replication settings, and replication history of a database. This section is new to Notes and Domino 6, although a lot of the information that buttons on this section expose was available in R5.
The Archive Settings button makes it easy to create and maintain time-based archives of the data that is no longer needed on a day-to-day basis. The basic archive settings are shown in Figure 2.13.
Figure 2.13. All databases can now be set up for archiving through the Archive Settings dialog box.
The Basics tab lets you choose the location of the archive; an archive can be local or server-based. Information about the last archival activity is also available. The Settings tab gives you access to many new features available in Notes and Domino 6 for archiving.
Although the dialog box is different, the encryption settings (simple, medium, and strong) are the same as discussed in the section "Securing a Local Database Through Encryption," earlier in the chapter.
When designing Domino applications, you need to understand the process of replication to take full advantage of the capabilities of Domino. Typically, mobile and remote users work on replicas of a database on their workstations, adding, updating, and deleting information. When users replicate with their server, their information and the server's information is synchronized. Their server can also replicate with other servers in their organization and with servers outside their organization, perhaps with a customer or a vendor. For example, information that the user enters on the workstation might eventually end up at a vendor's server.
The process of replication synchronizes information between the sender and the receiver over time. Therefore, if a user modifies a document in the database on the workstation and another user modifies the same document in the database on the server, when replication occurs, the two documents are compared for changes. If a setting in the form that created the document states that changes should be merged, both changes are recorded in the updated document. However, if this has not been set, a replication or save conflict would occur and both documents would be saved to the database with a warning. Someone then would have to manually resolve the problem.
On a workstation, replication can take place according to a predefined schedule that the user or administrator sets. Frequently, a user invokes manual replication at the desired time. Replication between servers, on the other hand, is scheduled by a connection document in the Domino directory. In either case, you can control which documents are replicated by a replication formula. You can use a replication formula to reduce the number of documents replicated to a particular user, thus enabling the user to see information only from his customers, for example. A replication formula might also be set up between servers, for example, to send only East Coast sales leads from the headquarters server to the East Coast server. Understanding this process helps you build better applications.
The Space Savers tab is displayed in Figure 2.14. The first check box on this screen is not really a replication setting at all, but one that helps to determine how document deletions are controlled. The setting Remove Documents Not Modified in the Last has two meanings. If the box is checked, this number ”90 days, by default ”controls when a document that has not been changed in any way is deleted from the database. So, for instance, if the box is checked and a document has not been modified for 90 days, that document would be deleted from the database. When the document is deleted, it leaves a deletion stub in its place. The deletion stub is an identifier of the original document, used to ensure that the document gets deleted on each replica copy of the database.
Figure 2.14. Automatic deletion of documents can be set in the Space Savers tab of the Replication Settings properties box.
The second meaning for this entry is the number of days before the deletion stub is purged from the database. This number is established by dividing the number in the Remove Documents Not Modified in the Last field by 3. For example, if I use the default of 90 for the number of days to delete documents, the purge interval would be 30 days.
Therefore, if a document gets deleted today because it has not been modified in the last 90 days, that document's deletion stub would then remain in the database for another 30 days before it would be purged.
The purge interval is independent of the check box for this option and is always one-third the number in the field. So even if I am not checking the box for automatic deletion, any document deleted by a user or through an agent has its deletion stub removed based on the number in that field.
This is important to remember because the purge interval, if set too low, could cause a document to not be deleted in all the replica copies. For example, if I set the number of days for deletion to 3, the purge interval would be one day. Now, if replication of the deletion stub of a document does not occur within that one-day time frame, the document would not be deleted in the other replica copies.
The second section of the Space Savers tab lets you specify a subset of documents to replicate. You can choose to replicate based on the contents of a view or folder, or based on a formula. This is good for laptop users who need to see only a subset of the documents in a database when they are on the road. However, this is not to be used as a security measure to guard against a user getting all the data in the database. The user can always change this formula or deselect the selection criteria and get all the documents.
The Send tab is displayed in Figure 2.15 and determines three things. The first setting, Do Not Send Deletions Made in This Replica to Other Replicas, determines whether deleted documents are replicated to other replicas. This is useful in very few instances, which include when you want each replica to maintain only those documents that seem important to the users of that replica.
Figure 2.15. The Send tab of the Replication Settings dialog box provides three settings that affect what is replicated.
The second check box determines whether a change to the title of a database or the catalog information, such as categories, is replicated. This is turned off by default and is usually not replicated. The final check box determines whether the local encryption properties are replicated. This is off by default and should rarely be used. Local encryption is used only when a mobile user carries a sensitive database replica on a laptop and wants to ensure that it cannot be read by an unauthorized user.
The Other tab of the Replication Settings dialog box displays additional settings for replication, as shown in Figure 2.16. Temporarily disabling replication can be useful if there is a problem with replication and someone needs to look into the matter. Scheduling the priority is up to the administrator because she will determine how replication is scheduled. The saved or modified date is automatically incremented and needs to be changed only if databases fall out of synch and a complete replication needs to take place. Again, this is usually something that the administrator does. The CD-ROM publishing date is useful for organizations that distribute a database on CD-ROM for installation on a server or user's workstation. The date makes it faster to do the first replication with the company because it scans only for new and modified documents that occur after that date.
Figure 2.16. On the Other tab of the Replication Settings dialog box, replication can be disabled on a specific replica copy of a database.
The Advanced tab of the replication settings for a database contains refinements to what can be replicated. Usually, the default settings are sufficient; however, when restricted information should be sent, the options here make it possible to determine what gets sent to whom, as indicated in Figure 2.17.
Figure 2.17. Further restrictions of replication can be set in the Advanced tab of the Replication Settings dialog box.
The Replication History button displays historical information, including the name of the server(s), the action, the date and time of the replication, and the filename of the replica copy of the database.
This section is new to Notes and Domino 6 and contains three settings:
Require SSL Connection
Don't Allow URL to Open
Requiring an SSL connection is a way to prevent unauthorized access to your database over the Web. By checking Don't Allow URL to Open, you restrict any URL that opens a database, and you keep Domino URLs from running against the database.
Database Basics Check Boxes
The check boxes at the bottom of the Basics tab are switches that control various settings. These settings include the following:
The Info tab has three sections: one labeled Size, one labeled Activity, and one for general database information. Three buttons on the tab provide additional detail, described in the sections on the Size and Activity areas. See Figure 2.18.
Figure 2.18. The Info tab of a database provides information about the replica ID of a database and the version of the ODS.
The Size section provides information about the physical size of the database file, as well as the number of documents in the database and the percentage of space used in the file. The amount of space used helps determine whether compacting the database is in order. If there is more than 10% free space, it is generally a good idea to compact the database to remove the free space and make the database operate more efficiently . This is particularly true if the free space is being overwritten, which is the default. If there is free space, Domino tries to reuse that space before writing to new space. This can result in a longer time when writing of documents than if all free space were recovered.
The Compact button in this section enables you to manually run the Compact utility to clean up the free space. You can run this on local databases and on server databases (as long as you have sufficient access). Your administrator typically has Compact set to run regularly on the server to ensure that databases maintain their efficiency and to conserve disk space. For local databases, such as a local replica of your mail database, you might want to check the space usage regularly and compact the database as needed.
The Activity section displays information about the dates when the database was created and last modified. It also logs activity for all users who have accessed the file. The User Detail button opens a dialog box in which the settings for logging this information is found, as well as the list of people and servers that have accessed the database, as shown in Figure 2.19. You can copy the history by clicking the Copy to Clipboard button and then pasting it into another document.
Figure 2.19. Reviewing user activity is helpful when trying to determine how much a database is being used. Note that you can mark the activity as confidential.
As indicated earlier, the replica ID is available from the Info tab. It provides a good reference when looking at two copies of a database to determine whether they are replicas or copies.
The On Disk Structure (ODS) version number corresponds to a release of Domino. Notes and Domino 6 has an ODS of 43, R5 has an ODS of 41, and so forth. The version number determines whether the Notes client can access the database locally. For instance, if an R5 client has an Domino 6 database on its hard drive, it will not be able to access that database because R5 cannot read the Domino 6 ODS. However, if that same database is on an Domino 6 server, the R5 client can access it because the server will do the translation. The ODS versions are shown in Table 2.4.
Table 2.4. Version Numbers
|Notes Release||ODS Number|
The Printing tab sets the default header and footer information for printing in the database. This property is very rarely used because it has little flexibility in determining what can be placed in these areas.
The Design tab controls many aspects of the database's design. Options for the Design tab are shown in Figure 2.20. Text at the top of the properties box in Figure 2.20 indicates that the design is not hidden; if it were, this tab would be blank and the statement "No Design Information Available" would appear in its place. Properties for template information and availability of a database from a database catalog or the File Database Open dialog box are also found on this tab. Database templates are described in detail in the section "Replacing the Database Design," later in this chapter. The option Do Not Mark Modified Documents As Unread is useful if you are tracking unread marks but do not want to refresh the marks if the document changes. If you want to include this database as part of a multidatabase site search, check the option Include in Multi-Database Indexing. Additional settings for multilingual databases appear at the bottom of the tab.
Figure 2.20. Among many other properties, the Design tab of the Database properties dialog box now lets you allow design locking of a database.
The Launch tab lets you determine what appears when the database is first opened. See Figure 2.21. Clicking the Preview Pane Default button in the middle of the Launch tab allows you to set the default location of the Preview pane (bottom right, bottom, or right). See Figure 2.22. The Launch options and their descriptions are listed in Table 2.5.
Figure 2.21. The Launch tab has settings for the Notes client and Web client, as well as a setting for the default location of the Preview pane.
Figure 2.22. The Preview pane can be set to three different default locations.
Table 2.5. Launch Options
|When Opened in the Notes Client:|
|Restore as last viewed by user||The default setting. It returns the user to the last location when the database was closed.|
|Open About database document||Opens the "About database" document. This is useful if users should see navigational buttons or information on this document every time they open the database.|
|Open designated Frameset||Opens the frameset that you specify. Many R5 and Domino 6 databases use this option.|
|Open designated Navigator||A Release 4 addition that is not used often with the advent of pages and framesets in R5.|
|Open designated Navigator in its own window||Opens a navigator or image map in a full screen.|
|Launch first attachment in About database||If an attachment is placed in an About document and this option is chosen , the attachment is launched when the database is opened.|
|Launch first doclink in About database||If a doclink is placed in an About document and this option is chosen, the doclink is launched when the database is opened.|
|When Opened in a Browser:|
|Use Notes launch option||The default; uses the choice made in the "When opened in the Notes client" section earlier in the table.|
|Open About database Document||Opens the "About database" document. This is useful if you store links in the About document.|
|Open designated Frameset||Opens the frameset that you specify.|
|Open designated Page||Opens the page that you specify.|
|Open designated Navigator in its own window||Opens the Navigator that you specify as a new page in the browser.|
|Launch first doclink in About database||Launches the first doclink in the "About database" document.|
|Launch designated doclink||Launches the doclink that you specify.|
|Launch first document in view||Launches the first document in a view.|
Two check boxes under the Launch tab are useful. The first, Show About Database Document If Modified, is useful for providing new instructional information to the users because it shows to a user only when it is modified.
The second, Show About Database Document When Database Is Opened for the First Time, is on by default. It is helpful to a new user because if the designer has included instructional information, it is displayed to the user here before the user actually enters the database. If the designer does not include information in this document, a blank screen appears, which is not very helpful!
Indexing a database to provide search capabilities is a great feature. However, the index can take a considerable amount of disk space and, for very large databases, can adversely affect server performance. You must have Designer or Manager access to create a full-text index. Information appears on this tab that indicates the size of the index and its properties. There are also buttons to create, update, or delete the index, as well as to count the unindexed documents. Creating a full-text index provides options for indexing attachments and creating case-sensitive indexes, as shown in Figure 2.23.
Figure 2.23. A full-text index can include the indexing of attachments, encrypted fields, sentence and paragraph breaks, and case-sensitive searches.
Indexing encrypted fields can violate security. Although the field information will not be directly displayed, searches can be run against the content (or suspected content) of an encrypted field.
You can set the update frequency of databases to Immediate (the default), Daily, Scheduled, or Hourly. This setting applies only to databases on a server and to local replicas of databases on a server. The index is then updated during replication.
Full-text indexes do have value to database construction. For example, full-text indexes can be used to search databases using the LotusScript and Java NotesDatabase methods FTSearch , FTSearchRange , UnprocessedFTSearch , UnprocessedFTSearchRange , Search , and UnprocessedSearch . You can also update or create a full-text index with the UpdateFTIndex method of LotusScript, and you can check whether the database already has a full-text index with the IsFTIndexed property of the NotesDatabase class.
The Advanced tab of the Database properties box gives you the ability to control settings that directly affect performance. These settings are shown in Figure 2.24. Each setting and its impact on performance is discussed in this section.
Figure 2.24. The advanced Database properties provide options for optimizing database performance.
Don't Maintain Unread Marks
By default, unread marks are maintained for each person accessing a database. You, as the developer, might not use the unread marks in your views, which means that this is then an unnecessary task. By removing the unread marks from the database, you enhance performance by not having to check and store that information for each user. You would definitely not check this option for mail databases because they make good use of unread marks: It is very important for users to know which mail they have or have not read. However, in a reference or help database, this is not important and, therefore, is not necessary to track.
Optimize Document Table Map
This option provides a way to manage the indexing and opening of views that select documents by form. If a database has a large number of these types of views, this option should be enabled. The value in the Form field for each document is stored in the view collection. When a view is refreshed, indexed, or opened for the first time, the view information is updated by looking at only those documents that use the forms indicated.
Don't Overwrite Free Space
When documents are deleted from a database, free space is created, which is then overwritten with a pattern to prevent unauthorized access to the data. This takes more I/O time to process and, therefore, can negatively impact performance. Free space is eventually reused as new documents are written to the database.
Choosing this option increases database performance because there is less I/O. However, the performance gain comes at the expense of data security. If the database is completely secure, or if security is not a concern, this option is a good choice. Similarly, if the deleted space is constantly reallocated in a heavily used database, this option is a good choice.
Maintain LastAccessed Property
Any time a user accesses a document to read or edit, the Last Accessed field on that document is updated if this property is turned on (the default is off). This can adversely impact performance by increasing the disk I/O. The only time you should use this is when you have document archiving set up for the database based on when documents were last accessed.
Disable Transaction Logging
This option is displayed only if transaction logging is turned on in the server document in the Domino directory. Transaction logging provides a means of recovering the document changes, additions, and deletions within a database after a server crash. Certain tape-backup utilities also use transaction logging to perform incremental backups of Domino databases. When transaction logging is enabled, all transactions are logged to files on a separate hard disk. If there is a server crash, the transaction log is used at server startup to apply any transactions that were not written to the database when the crash occurred. Disabling the transaction log can improve performance, but you must balance that with the risks of potential data loss.
Allow Soft Deletions
Very often, a user complains that she deleted a document or a group of documents that she did not mean to delete. If you enable soft deletions, documents can be undeleted. This option requires that you place a time period on the documents that can be recovered in the Soft Delete Expire Time in Hours field at the bottom of the dialog box. It also requires that you create a view to display deleted documents so that they may be undeleted. The Notes and Domino 6 mail database utilizes this technique, providing access to deleted documents in the Trash view.
Don't Support Specialized Response Hierarchy
By default, Notes maintains parent/child properties of documents. Certain view formulas, including @AllChildren and @AllDescendants , make use of these properties. You can improve performance by turning off this property, stopping Notes from maintaining this information. This also sets the NotesDocument.Responses to 0 documents. For this setting to take effect, you must compact the database, using the “h setting if the database is on a server.
Don't Allow Headline Monitoring
Users can subscribe to databases to monitor the data that is most interesting to them. This can affect the performance of the server if many people decide to monitor a database because the database must be scanned each time documents are added. Consider turning on this option if headline monitoring is not a requirement. Administrators can turn off this option at the server level.
Allow More Fields in Database
The total number of characters allowed for all field names concatenated in a database cannot exceed 64KB, by default, which is an average of 3,000 fields. By turning on this property, this number increases to 23,000 fields.
Use LZ1 Compression for Attachments
The new LZ1 compression method is faster than the Huffman method. However, you should use this only in Notes and Domino 6 environments. In mixed Domino 5 and Domino 6 environments, the server uses the Huffman method.
Limit Entries in $UpdatedBy Fields
Each document that is created contains an $UpdatedBy field that stores the names of the users or the servers that have edited the document. If this is not a requirement for the database, it is a good idea to limit the number of entries kept to conserve disk space and increase database performance.
Limit Entries in $Revisions Fields
Each document that is created contains a $Revisions field that stores the date and time of an editing session for a document. Domino uses the contents of this field to determine how it should resolve replication and save conflicts. A replication conflict occurs when a document is edited by people accessing the database from two different server replicas of a database and when the database is subsequently replicated. A save conflict occurs when two people edit the same document on the same server at the same time. The number of default entries that the $Revisions field stores is 500, and each entry consumes eight bytes of disk space. Eventually, maintaining revision history for a database with a high number of documents can take a considerable amount of disk space. By limiting the number of entries in the $Revisions field, you can reduce the amount of space consumed by the contents of this field in each document. Consider setting this to a value of 10 or less because it usually is not important to have any history beyond the last 10 edits.
Soft Delete Expire Time in Hours
This property is used in conjunction with the soft deletion property discussed earlier and has no meaning alone. Keep in mind that this value is in hours. For example, if you want the undelete capabilities for two days, you enter 48 hours.
Part I. Introduction to Release 6
Whats New in Release 6?
The Release 6 Object Store
The Integrated Development Environment
Part II. Foundations of Application Design
Advanced Form Design
Using Shared Resources in Domino Applications
Using the Page Designer
Adding Framesets to Domino Applications
Automating Your Application with Agents
Part III. Programming Domino Applications
Using the Formula Language
Real-World Examples Using the Formula Language
Writing LotusScript for Domino Applications
Real-World LotusScript Examples
Writing Java for Domino Applications
Real-World Java Examples
Enhancing Domino Applications for the Web
Part IV. Advanced Design Topics
Accessing Data with XML
Accessing Data with DECS and DCRs
Security and Domino Applications
Creating Workflow Applications
Analyzing Domino Applications
Part V. Appendices
Appendix A. HTML Reference
Appendix B. Domino URL Reference