Chapter 15: Using Workgroup Features and Applications with MS Office

This chapter covers issues and features you need to know about when your users share documents throughout the organization. Included in this chapter is managing documents in your organization using the Find File feature, setting up and using electronic mail to exchange documents, using ODBC (Open Database Connectivity) and external data in Office applications, plus information about specific new workgroup features in the Office for Windows 95 applications. These new features include Shared Lists in Microsoft Excel, PowerPoint Presentation Conferencing and exchanging content with Microsoft Word, using Word Viewer, using the Word Internet Assistance, and creating a document library.
Using Microsoft Bookshelf For Windows 95 in a Workgroup
This section describes how to use Microsoft Bookshelf for Windows 95 on a network. It explains how a network administrator can install Bookshelf on a network and how users can install Bookshelf on their workstations over the network.
How to Use Bookshelf On a Network
The following instructions are for a server/workstation environment where Windows system files for every workstation exist on each workstation and are not shared. If the Windows system files are shared on the server, see the section, “How to Use Bookshelf on a Network With Shared Windows” below.
Using Bookshelf as a shared application requires a two-step installation. First, you must configure the server to share the CD-ROM drive; second, each workstation user must install Bookshelf from that server.
STEP 1 - Configure the server to share Bookshelf CD-ROM
To prepare the server to share the CD-ROM, complete the following steps:
 1.	Before installing Bookshelf as a shared application, be sure the network software is installed and operating properly. 
 2.	Enable network access to the server’s CD-ROM drive. Refer to the Windows 95 or Windows NT documentation for details on how to share the CD-ROM drive on the network.
 3.	Ensure each workstation that will be running Bookshelf has read access to the Bookshelf CD-ROM drive.
  
STEP 2 - Install application files on each workstation
Next, each workstation needs to install Bookshelf from the server using the following steps:
 1.	Connect a drive letter to the shared CD-ROM drive on the server.
	Note    The drive letter used to connect to the Bookshelf CD should remain the same in order for Bookshelf to run properly. If the drive letter changes, Bookshelf will prompt for the new drive connection.
 2.	From the Explorer (Windows 95) or File Manager (Windows NT), double-click Setup.exe on the Bookshelf CD.
 3.	Follow the instructions on the screen to complete the installation.
 4.	Repeat steps 1 through 3 for each workstation on which Bookshelf is being installed.
  
How to Use Bookshelf on a Network With Shared Windows
The following instructions are for a server/workstation environment where Windows system files for every workstation are in one shared Windows directory on the server, such as with diskless workstations connected to a server. 
  
Note   With this configuration there are certain limitations: 
  
·	The system administrator must first install Bookshelf from a workstation with privileged server write permissions for the shared Windows system directory. 
·	Due to the high network traffic, movies and audio may be choppy, even for a single user. 
·	Workstations must restart windows after running setup in order for sound to work. Setup will not tell you this nor will it perform the operation for you. 
  
Using Bookshelf as a shared application requires a three-step installation. First, you must configure the server to share the CD-ROM drive. Second, you must install Bookshelf from a workstation with full access to the shared Windows directory. Third, each individual workstation user must install Bookshelf from that server.
STEP 1 - Prepare server to share Bookshelf CD-ROM
To prepare the server to share the CD-ROM, use the following steps:
 1.	Before installing Bookshelf as a shared application, be sure the network software is installed and operating properly. 
 2.	Enable network access to the server’s CD-ROM drive. Refer to the Windows 95 or Windows NT documentation for details on how to share the CD-ROM drive on the network.
 3.	Ensure each workstation that will be running Bookshelf has read access to the Bookshelf CD.
  
STEP 2 - Install shared application files on a server
The system administrator must now set up Bookshelf from a workstation with full access to the shared Windows directory. Full access is needed since Bookshelf installs files into the shared Windows directory. Once these files are installed, individual workstations without full access will be able to set up Bookshelf 95. 
On a workstation with write-access to the shared Windows directory, install Bookshelf from the server using the following steps:
 1.	Connect a drive letter to the shared CD-ROM drive on the server.
	Note    The drive letter used to connect to the Bookshelf CD should remain the same in order for Bookshelf to run properly. If the drive letter changes, Bookshelf will prompt for the new drive connection.
 2.	From the Explorer (Windows 95) or File Manager (Windows NT), double-click Setup.exe on the Bookshelf CD.
 3.	Follow the instructions on the screen to complete the installation.
  
STEP 3 - Install application files on a workstation
Next, each workstation needs to install Bookshelf from the server using the following steps:
 1.	Connect a drive letter to the shared CD-ROM drive on the server.
	Note    The drive letter used to connect to the Bookshelf CD should remain the same in order for Bookshelf to run properly. If the drive letter changes, Bookshelf will prompt for the new drive connection.
 2.	From the Explorer (Windows 95) or File Manager (Windows NT), double-click Setup.exe on the Bookshelf CD.
 3.	Follow the instructions on the screen to complete the installation.
 4.	Restart Windows. 
	Note    Setup does not ask the user to restart Windows, but in this configuration, it is important for the user to restart Windows after Bookshelf finishes installing. This allows for sound to be initialized for use with Bookshelf.
 5.	Repeat steps 1 through 4 for each workstation on which Bookshelf is being installed.
  
Enhancing Bookshelf Performance on a Network
Bookshelf shared over a network may exhibit lower performance than Bookshelf installed on a user’s local hard disk drive. This is due to the relatively slower speed of the CD-ROM drive compared to a hard disk drive, and busy network traffic.
To improve the performance of Bookshelf, there are several things that can be done.
·	Install a fast CD-ROM drive. The faster the data transfer rate and seek time in the CD-ROM drive, the better the performance. For a server, it is highly recommend that a newer “multi-spin” type CD-ROM drive be used.
·	Use CD-ROM caching. Reading information from disk is a bottleneck for most computers, and current CD-ROM drives are especially slow at this. Therefore, CD-ROM caching utilities can help reduce the number of reads that need to be made by allowing the computer to hold large parts of data from the CD in memory. Refer to your network operating system manuals about caching CD-ROM drives.
·	Increase the server’s memory.    With more memory, the server can operate more efficiently when multiple workstations are attached. In conjunction with disk caching utilities, more memory will significantly improve performance.
·	Copy the entire Bookshelf CD to a hard drive.    If the server has a large hard disk drive with at least 680MB of free space, Bookshelf can be transferred to the hard disk drive in its own network accessible directory. Accessing Bookshelf on a hard disk drive will be faster than accessing it on a CD-ROM drive.
·	Use a dedicated network server and operating system.   Dedicated servers and high end network operating systems can deliver greater overall performance.
  
There are also many way to improve the overall performance of Windows on the Workstations.  For more information on optimizing Windows, see your Windows documentation.
Finding and Managing Documents within a Workgroup
In Office 4.x applications, users could search for documents with the Find File command on the File menu. In Office 95, full text searching is integrated directly into the Open dialog box of all Office applications, so finding files is much simpler and faster.
The Find Fast utility included with Office 95 creates an index of all Office document types (for example .doc and .xls files) on a local, shared or network drive. The index includes information about document content and properties. The Find Fast utility can take advantage of multitasking under Windows 95 and Windows NT to update its indexes automatically in the background, so no user action is required. Searching with a Find Fast index is much faster than searching without one; searching speed can decrease by as much as 100 times with an index.
If your workgroup stores documents on a network or shared drive, they can share the same index of the documents on the drive. The user that creates, updates or deletes an index on a network drive must have write permission on that drive.
The index files created by the Find Fast utility are stored in the same location as the files indexed. The index files are hidden and have the extension pattern .ff*. The index files typically require about 7 percent of the space of the text component of the documents they index, or about 1 percent to 3 percent of the total document size. Documents created with Office 95 applications produce a more efficient index/document size ratio than do documents created with previous Office applications.
  
Note   The Find Fast utility is not associated with the Find command on the Windows Start menu. The Find command on the Windows Start menu searches only by filename; the Find Fast utility allows for searches by filename and content.
  
Find Fast Service for Windows NT Servers
Microsoft Office includes a Find Fast utility designed to run on an end user’s computer. This indexer builds indexes that make content and property searches from the Open dialog box in any Office applications substantially faster. 
The Office Resource Kit CD includes a version of the Find Fast indexer called Find Fast NT that is packaged for use as an NT service. Included in the Office Resource Kit CD is a Setup program that copies the Find Fast NT program and related files and makes the necessary Registry entries. This Setup program also calls a custom action to create an NT service for Find Fast. For installation instructions, see Appendix D, “Contents of the Office Resource Kit CD.”
Find Fast NT runs directly on a Windows NT server. This allows you to index documents on a Windows NT server without increasing network traffic or taking up resources on users’ computers.
Find Fast NT runs without a user logon and has admin privileges to access the files of the Windows NT server on which it is running. However, Find Fast NT does not have user privileges and consequently, cannot usually be used to create or update non-local indexes over the network.
Find Fast NT is typically used by system administrators to schedule the creation and automatic updating of indexes on an NT server.
The Find Fast NT user interface is identical to that of the regular Find Fast utility for single-user computers. Find Fast NT allows the same control over the folders and document types to be indexed.
When the Find Fast utility for single-user computers is installed on an end user’s computer with more than 8 MB of RAM, it automatically creates indexes of local drives. Find Fast NT, on the other hand, does not create indexes automatically. A system administrator with admin privileges on the NT server must create indexes manually. The steps for creating an index in Find Fast NT are identical to those followed in the Find Fast utility for single-user computers. 
To create an index
 1.	In the Windows NT Control Panel, double-click Find Fast NT.
 2.	On the Index menu, click Create Index.
 3.	Follow the instructions on your screen.
  
Indexes created by the Find Fast utility for single-user computers and by Find Fast NT are identical. The index is stored in hidden files (with the filename extension “.ff*”) in the uppermost folder included in the index. A single index is used by all Office users who have at least read permission to search the folder covered by an index or any of its subfolders. The index files typically require about 7 percent of the space of the text component of the documents they index, or about 1to 3 percent of the total document size.
Office applications automatically use the indexes, when available, whenever a user conducts a search in the Open dialog box. Therefore, it is very important to keep indexes built by Find Fast NT up to date. Otherwise, as the indexed files change, the indexes become out of date and searching gradually slows down. Also, search results may be initially inaccurate until Find Fast NT completes background indexing.
  
Note   Find Fast NT should never be installed on the same computer as the Find Fast utility for single-user computers that ships with Office. Find Fast NT is not meant to be run on the same computer as the Find Fast utility for single-user computers. Find Fast NT is designed to run on NT servers, whereas the Find Fast utility is designed for single-user workstations
  
What happens if users install both Find Fast NT and the Find Fast utility for single-user computers on the same computer anyway? Usually only Find Fast NT will run. There are two possible scenarios to consider, which are described in the following section.
Installed Find Fast NT, then Installed Find Fast Utility for Single-User Computers
Users could attempt to install the Find Fast utility for single-user computers as part of an installation of Office, Word, Microsoft Excel, or PowerPoint. In a typical installation on a computer with less than 8 MB of RAM, Setup will attempt to schedule the creation of indexes with root-level coverage on local drives. The attempt to create root-level indexes will fail if indexes are already present on local drives. This is typically the case if Find Fast NT is already running. 
Setup will also attempt to start the Find Fast utility for single-user computers. If Find Fast NT is already running, the start of the Find Fast utility for single-user computers will fail because only one Find Fast can run at one time on a single computer. If Find Fast NT is not currently running, then the Find Fast utility will run.
Finally, Setup will create an entry for Find Fast in the Startup group so that the Find Fast utility for single-user computers starts as a background utility at startup. However, Find Fast NT is typically configured as an NT service that starts with each startup of the NT computer. Because this launch happens before the Startup group starts, and because only one version of Find Fast can run, the Find Fast utility for single-user computers in the Startup group will be ignored.
In the Control Panel, users will see both a Find Fast icon and a Find Fast NT icon. Clicking either icon will reference the same registry key (Hkey_Local_Machine\Software\Microsoft\Shared Tools Location\Findfast), which, after completion of the setup of the Find Fast utility for single-user computers, now points to Findfast.exe. Any attempt to launch this program will fail.
Installed Find Fast Utility for Single-User Computers, Then Installed Find Fast NT
After Setup restarts the computer, Find Fast NT will be the first to run, thus blocking execution of the Find Fast utility for single-user computers. As in the other installation order, Find Fast NT and the Find Fast utility for single-user computers share the same Registry settings, including settings to determine indexing tasks (create, update, automatically update) that should be completed. Find Fast NT will usually fail on tasks involving shared network drives that require user privileges.
Again, users will see both a Find Fast icon and a Find Fast NT icon in the Control Panel. Because Find Fast NT was the last to install, its registry settings are in effect. Selecting either icon will attempt to start Find Fast NT. If the user does not have admin privileges, this attempt will fail.
Remote Administration
Find Fast NT does not support remote administration. Commands used to create, update, or delete an index and all other Find Fast NT commands must be issued from the Find Fast NT Control Panel running locally on the NT server. The indexing log, with status on recent indexing tasks, is saved in Ffastlog.txt (usually in the Windows\System folder) and can be accessed remotely (in NotePad, for example).
Security Issues for the Find Fast Utility
As a general rule, it’s more efficient in terms of disk space, index time, and search time to work with a single large index, even at the root level, rather than with several smaller indexes. However, this introduces some security implications:
·	Everyone with read permission to the index should at least have read permission for all documents covered by the index.
·	If a remote user attempts to update an index remotely from the Find Fast utility, this user should have write permission to all documents covered by the index. In any case, remote updates are not necessary if Find Fast NT is running on the server.
·	Users of shared network drives will be unable to access an index in a parent folder. When creating an index, use the In And Below box in the Create Index dialog box to avoid security and share problems.
  
Setting Up Automatic Indexing
All users share the same indexes for network servers. It is important to keep the indexes up-to-date, otherwise search results will become inaccurate. By default, Find Fast NT, like the Find Fast utility, is set to update indices automatically. 
To update an index automatically
 1.	On Windows Start menu, point to Settings, and then point to Control Panel. 
 2.	Double-click Find Fast. 
 3.	Select the index you want to work with.
 4.	On the Index menu, click Update Index.
 5.	Make sure the Continue to update automatically box is checked.
  
Selecting the Types Of Files You Want Indexed
When you create an index, you select what types of files you want indexed. 
To select file types for indexing
 1.	On Windows Start menu, point to Settings, and then click Control Panel. 
 2.	Double-click Find Fast. 
 3.	On the Index menu, click Create Index.
 4.	Under Index For Documents In And Below, select the drive and folder that contain the documents you want indexed.
 5.	In the Of Type box, select the file types you want indexed. To index all possible file types, select All Files. The Find File utility will then index all the file types listed in the Of Type box, plus file types for which you have installed converters for Office applications such as the WordPerfect converter installed with Word.
  
Interoperability with Electronic Mail
This section covers electronic mail compatibility and other workgroup features of Office.
Mail-Enabling Applications
The Office applications include commands to send and route documents via e-mail. These commands work with simple MAPI systems as well as MAPI 1.0 or greater, such as Microsoft Mail 3.x and the Microsoft Exchange client included with Windows 95, and 16-bit VIM-based mail systems including cc:Mail and Lotus Notes. This section describes how Office Setup mail-enables the applications, how to configure Word as the user’s e-mail editor, and how to use the mail commands from within the applications.
  
Note   16-bit VIM support is not available on Windows NT systems.
  
Setting Up Mail Support
Because Office Setup automates installation of e-mail support, you should install and set up e-mail client software on user systems before installing Office. If users have more than one e-mail client, they can designate during setup which client the Office applications should use. 
The following files are used for e-mail support:
  
Filename	Location	Installed by	Purpose

Mapi32.dll	Windows\System	Windows 95 (Microsoft Exchange client)	Provides 32-bit MAPI support
Mapivi32.dll	Windows\System	Office 95	Provides mail support for 16-bit VIM systems
Mapivitk.dll	Windows\System	Office 95	Communicates with the 16-bit VIM provider
32-bit MAPI and 16-bit VIM support can coexist on one system, but the Office applications can be enabled to use only one system, as follows.
Office Setup detects whether Vim.dll, a component of the cc:Mail or Lotus Notes Mail client software, is installed on the user’s system. If so, Setup installs Mapivi32.dll and Mapivitk.dll. If Setup also detects Mapi32.dll, indicating that a MAPI mail provider is present, Setup prompts the user to specify which mail system to use.
When it installs VIM support, Setup adds a registry entry to specify which DLL to use for e-mail functions by the Office applications. If you change or upgrade your mail system after installing Office, you can create an installation script to install or remove the files listed in the table above, and modify the registry entry on the user’s system to enable the support for the new e-mail system. For more information about registry entries, see Appendix B, “Registry Keys and Values.” For more information about creating an installation script, see Chapter 9, “Customizing Client Installations.”
Setting Up WordMail Support
Users of the Microsoft Exchange client can use Microsoft Word as their e-mail editor. Word as the e-mail editor (WordMail) makes the Word editing and formatting features available for composing e-mail, while maintaining compatibility with other plain-text e-mail systems.
WordMail requires a minimum of 8MB of memory to run, but 12MB is recommended. Both the Microsoft Exchange client default mail editor and WordMail create messages in Rich Text Format (RTF), which are generally somewhat larger than plain-text files.
The Microsoft Exchange client must be installed first, before installing WordMail.. Word can be used as editor only with the Microsoft Exchange client, not with other e-mail client software. If you upgrade a system to use the Microsoft Exchange client after installing Office, and you’ve already specified that WordMail be installed, the only thing you have to do to enable it is to launch Exchange and click WordMail Options on the Compose menu. Select the Enable Word as E-mail Editor check box to use Word as your e-mail editor. Otherwise, you must add the WordMail capability by running the Office Setup program. WordMail is included in the Custom/Complete installation, as an option under Microsoft Word, and is not included in Typical and Compact installations.
After installation when Exchange is already present, WordMail is enabled automatically. To disable WordMail after installation, use the WordMail Options command on the Compose menu in the Microsoft Exchange client, and clear the Enable Word As E-mail Editor check box.
WordMail does not support custom extensions (add-ins). If you install custom extensions to the Microsoft Exchange client, you must disable WordMail (clear the Enable Word As E-mail Editor check box) to use the extensions.
  
Note   Schedule+ meeting requests and undeliverable message reports are plain text. These messages do not use WordMail regardless of the option setting.
  
Setting Up E-mail Templates
By default WordMail uses the Email.dot template when composing messages. This template provides the styles for message headers and also provides shortcut key functions.
By changing this template, you can customize the feel and appearance of the message headers, forward and reply headers, fonts, and default message text to suit your site’s needs. If you want to set up customized WordMail templates for your site, base them on a copy of Email.dot so as not to lose the basic characteristics provided by this template. For example, if you want to customize the WordMail toolbars, you can do so from Word, by writing a macro in Email.dot or in a customized copy of this template.
Using Word to Compose and View Mail
WordMail gives e-mail users access to the majority of Word features, including formatting, AutoCorrect, spell checking, and macros. The highlighter tool is particularly useful to mark areas of interest in long messages and replies.
A few Word features are unavailable in WordMail:
·	The New and Save All commands are not included on the File menu. Use the Compose command from the Microsoft Exchange client to start a new WordMail message. Because each message is in its own window, Save All is not needed.
·	The Templates command is not included on the File menu. To change the template used for WordMail messages, use the WordMail Options command on the Compose menu in the Microsoft Exchange client. Users cannot change the template for a message after they open or start composing the message.
·	The Add Routing Slip and Post To Exchange Folder commands are not included on the File menu. Users can post documents directly from the Microsoft Exchange client, or create a document in Word and then route or post it.
·	Print preview is not available. If users need to preview a WordMail message, they can paste the message into a regular Word document to view it before printing. The message headers (name, address, and subject lines) are always printed. If users want to preserve the pagination in a message, they can set a page break at the beginning of the message text, so that the headers print on a separate page.
·	The MailMerge and Envelopes And Labels commands are disabled on the Tools menu. Users who want to use WordMail messages in mailings can copy the message into a separate Word document.
·	The Customize command is disabled on the Tools menu. To change the WordMail toolbars, work in Word and write a macro in Email.dot or in a customized copy of the Email.dot template.
·	The Window menu commands are not included, because each WordMail message has its own window. Users who want to view the message in split windows can copy the message to a separate Word document.
  
Sending Messages Between WordMail and Other Mail
Both Microsoft Exchange and WordMail save the mail file in Rich Text Format (RTF). For compatibility with other mail clients and editors, WordMail messages are saved in both RTF and plain text. Recipients who do not have WordMail, such as users of Microsoft Mail or cc:Mail, receive the plain text version.
In the conversion to plain text, special characters, such as a registered trademark symbol, are converted to the nearest plain text representation, such as “(R)”. The same is true of bulleted and numbered lists. Tables become a tab-delimited list. Hidden text is not displayed. Revision marks and annotations remain in your message. WordMail templates are lost. Attachments remain in the message. If the message is then sent back to WordMail from the plain-text system, all of the special characters remain plain text.
The standard editor for the Microsoft Exchange client supports some but not all of the RTF features available in WordMail. If e-mail is sent from WordMail to a user running Microsoft Exchange client but not using WordMail, most of the rich text format is preserved, although there are some exceptions. Tables are displayed as tab-delimited text. Borders and shading are not displayed. Colors such as those used for revision marks are displayed, but may be a different color. If e-mail is then returned from a Microsoft Exchange client to WordMail, nothing is lost from the original mailing as the mail remains in RTF format.
Using the Mail Commands
When mail-enabled as described previously, Word, Microsoft Excel, and PowerPoint all provide Send and Add Routing Slip commands on the File menu. Microsoft Access provides only the Send command; users of Microsoft Access who want to route information can first export it to one of the other Office applications. The Send command launches the e-mail client software and creates a new message that includes the document as an attachment. The Add Routing Slip command displays a routing slip dialog box in which the user enters and orders the recipients, and can add an accompanying message.
When Office is installed on a system that has the Microsoft Exchange client and Microsoft Exchange Server access, the applications also have the Post To Exchange Folder command on the File menu. As for routing, Microsoft Access does not have this command but users can export data to another Office application for posting. The post command allows the user to place a copy of a document directly in a public folder so that other users can access it. For more information, see the documentation for Microsoft Exchange Server.
Users who convert to WordMail from the standard Microsoft Exchange client editor should be made aware of some differences in its commands and behavior:
·	To set the priority, read receipt, and similar options, use the Properties button.
·	Print preview is not available in WordMail.
·	Running a regular Word session at the same time as a WordMail session can cause some confusion. Because one executable supports both sessions, if the user opens a dialog box such as Options in the regular session, the WordMail session does not respond to commands until the user closes the dialog box.
  
Using Address Books
Word and WordMail allow users to pick addresses from the MAPI Personal Address Book (PAB) or the Schedule+ Contact List. The Insert Address button on the standard toolbar provides a list of either the first few names in the address book or the names most recently selected by the user, and also provides access to the address book browser.
The content and layout of the inserted address are determined by the AutoText entries NameLayout and AddressLayout. You can modify these AutoText entries to conform to the addressing requirements of your local e-mail system.
The following properties identify the fields in the address book:
PR_TITLE
PR_GIVEN_NAME
PR_SURNAME
PR_STREET_ADDRESS
PR_POSTAL_ADDRESS
PR_POSTAL_CODE
PR_STATE_OR_PROVINCE
PR_POST_OFFICE_BOX
PR_DISPLAY_NAME
PR_EMAIL_ADDRESS
PR_ADDRTYPE
PR_COMPANY_NAME
PR_DEPARTMENT_NAME
PR_COUNTRY
PR_BUSINESS_FAX_NUMBER
PR_BUSINESS_TELEPHONE_NUMBER
PR_BUSINESS2_TELEPHONE_NUMBER
PR_ASSISTANT
PR_ASSISTANT_TELEPHONE_NUMBER
PR_PAGER_TELEPHONE_NUMBER
PR_CELLULAR_TELEPHONE_NUMBER
PR_HOME_FAX_NUMBER
PR_HOME_TELEPHONE_NUMBER
PR_PRIMARY_FAX_NUMBER
PR_PRIMARY_TELEPHONE_NUMBER
PR_OFFICE_LOCATION
PR_LOCALITY
PR_LOCATION
The default NameLayout and AddressLayout AutoText entries are as follows, where | means “or,” braces enclose alternatives, and \r means carriage return.
NameLayout:
{<PR_GIVEN_NAME> <PR_SURNAME> | <PR_DISPLAY_NAME>}
AddressLayout:
{{<PR_GIVEN_NAME> <PR_SURNAME> | <PR_DISPLAY_NAME>}\r}
{{<PR_STREET_ADDRESS>\r}
{{<PR_LOCALITY>}{, <PR_STATE_OR_PROVINCE> <PR_POSTAL_CODE>}\r}
{<PR_COUNTRY>\r}
| <PR_POSTAL_ADDRESS>\r}
The address book capability has the following limitations:
·	For users to have access to the MAPI PAB, MAPI support, such as that provided by the Microsoft Exchange client, must be installed on the users’ systems.
·	The Schedule+ Contact List is a feature new to Schedule+ 7.0. Schedule+ 1.0 users must upgrade to the new version to be able to set up a Contact List.
·	The address book capability is not available on Windows NT.
  
Working with Notes/FX
The Office applications support Lotus Notes/FX 1.0 and 1.1 through extensions to OLE. Although no capability to post directly to a Notes database is provided, users can embed documents created by Office applications, including Office Binders, in a database. Users can open and modify the embedded documents. When the user issues a File Update command from within the document or closes and saves the Notes message, the changes are written to the Notes database.
Each Office application exposes a set of properties listed on the General, Summary, and Statistics tabs in the Properties dialog box to Notes/FX. In addition, any custom properties that you create beginning with PROP_ are exposed to Notes/FX. You can set properties for Notes/FX in a document using the Properties command on the File menu. Use the Custom tab to define properties you want to make available for Notes/FX.
Office Setup automatically installs Notes converters in the Notes folder. The Microsoft Excel, PowerPoint, and Word converters each register the file Mscthunk.dll in the Notes.ini file so that it is available in the converters list in the Notes client. A helper file, _msimp32.dll, is also installed in the Notes folder. These files are rich text field converters. Microsoft Excel and Word call the text converters Excel32.cnv and Mswrd632.cnv respectively, in the regular shared components folder. 
The text converters only allow for importing text into Notes. Microsoft Excel also has view import (_ixls.dll) and export (_xxls.dll) converters that are installed in the Notes program folder.
  
Note   Notes/FX support is not available on Windows NT.
  
Working with Microsoft Exchange Server
In addition to e-mail support, Microsoft Exchange Server allows users to post documents to public folders for sharing with other workgroup members. To enable posting capability, users must install the Microsoft Exchange client included with Microsoft Exchange Server, and then install Office. When installed in this order, the command Post To Exchange Folder is added to the File menu for each application. Public folders are available only when the user has access to a Microsoft Exchange Server system.
Users can post documents directly from the Office applications to any public folders for which they have permissions.
To post an Office document to a public folder
 1.	Log in to your Microsoft Exchange server.
 2.	Open the document that you want to share with other Microsoft Exchange users.
 3.	On the File menu, click Post To Exchange Folder.
 4.	Select the public folder to receive the document.
  
For information about setting up Microsoft Exchange Server and making public folders available to users, see the documentation accompanying the Microsoft Exchange Server software. For more information about working with public folders, see “Interface with Microsoft Exchange” in Chapter 1.
Custom Properties and Views
Using Microsoft Exchange Server, you can create custom views of the information stored in public folders. Custom views allow you to select what details are displayed about the stored information, and in what sequence. For Office documents, custom views can make use of the properties stored with each document. You can create custom properties for use in your custom views. For example, a view could list information about all documents associated with a particular project using a custom Project Name property.
To create and use custom views, you need to install the enhanced Microsoft Exchange client provided with the Microsoft Exchange Server. This version of the client software provides some additional capabilities to supplement the basic functionality provided in the client software included with Windows 95. For information and details, including instructions for creating custom views, see the documentation accompanying Microsoft Exchange Server. For more information about standard and custom properties, see “Implementation of Properties” and “Sources of Properties” in Chapter 1.
Working with Microsoft Mail
Microsoft Mail 3.x clients have the following limitations:
·	They cannot use WordMail. In a mixed e-mail environment, WordMail messages from other users are delivered to Microsoft Mail clients as plain text.
·	They cannot post documents to public folders from within the Office applications. This capability requires the Microsoft Exchange Server and client software.
  
Working with Lotus Notes Mail and cc:Mail
Lotus Notes Mail or cc:Mail clients have the following limitations:
·	They cannot use WordMail. In a mixed e-mail environment, WordMail messages from other users are delivered to these clients as plain text.
·	They cannot post documents to public folders. This capability requires the Microsoft Exchange Server and Client software.
  
For information about installing support for Lotus Notes Mail and cc:Mail, see “Mail-Enabling Applications” earlier in this chapter.
Working with Other Mail Systems
Because Microsoft Exchange is the message editor used on the Microsoft Network (MSN), WordMail replaces the standard MSN read and compose note when the user enables WordMail.
With Windows 95, any user with a modem has access to Internet electronic mail using MSN. Similarly, because Windows 95 includes CompuServe mail capability for Microsoft Exchange, any user who has a CompuServe account can use the Microsoft Exchange client, and WordMail, to receive and compose e-mail.
For information about MSN connectivity and e-mail Internet access, see chapters 29 and 30 in the Microsoft Windows 95 Resource Kit, respectively.
Supporting Mailing, Routing, and Posting
The new WordMail and Office Binder features may increase the e-mail traffic on your network. Both Microsoft Exchange and WordMail messages are somewhat larger than plain-text messages. This is true especially if your environment mixes WordMail and plain-text e-mail clients, because plain-text clients receive both plain text and Rich Text Format versions of messages from WordMail users. WordMail messages are slightly larger than Microsoft Exchange messages, but are actually smaller than a Word document sent as an attachment to an e-mail message. Office Binder files easily grow quite large and can result in large messages if mailed.
Provide the following guidelines to your users to encourage optimal use of network resources:
·	When one copy of a document can be passed from one recipient to another, encourage users to route the document instead of mailing a separate copy to each recipient.
·	Let users know the maximum message size accepted by your e-mail system, and explain what happens when they exceed this size.
·	Encourage users to consider alternatives to mailing large documents. Users can copy large documents to a network share and mail links to the shared file using the Windows Package application. If your site has Microsoft Exchange Server, users can post large documents to public folders. Alternatively, users can share their computer or a folder on their computer over the network.
  
ODBC and Client/Server Operations
In a client/server application, you store your data in remote tables on a database server, such as Microsoft SQL Server, instead of in local tables in your Microsoft Access database. Your Microsoft Access database, the client, sends queries and updates to the server and retrieves the data it needs. A client/server application takes advantage of the processing power available to both the client and database server components. 
By contrast, in a file server application, data simply resides on a network file server; transactions with the data are handled no differently than the reading and writing of any other file on the network, and all processing is performed locally. 
Developing, optimizing, and maintaining client/server applications is a complex subject. This section briefly describes what Open Database Connectivity (ODBC) is and how it allows you to interact with a large variety of Structured Query Language (SQL) data sources. The reasons to adopt a client/server approach are covered, as are the issues involved in converting an existing an Microsoft Access application to a client/server application. For more information about developing client/server applications using Microsoft Access, see Building Applications with Microsoft Access for Windows 95.
Open Database Connectivity (ODBC)
Providing data access to the large variety of database applications can be very complex. Applications that use the ODBC standard, such as Microsoft Access and Microsoft Excel, ease this burden by using a vendor-neutral means of accessing database management systems (DBMS). Microsoft has gained very broad support for ODBC, which allows you to access a broad variety of data sources.
ODBC provides many significant benefits by providing an open, standard way to access data.
·	ODBC allows users to access data in more than one data storage location (for example, more than one server) from within a single application.
·	ODBC allows users to access data in more than one type of DBMS (such as DB2, ORACLE, DEC RDB, Apple DAL, dBASE, and Microsoft SQL Server client-server database management system) from within a single application.
·	ODBC greatly simplifies application development — it is now easier for developers to provide access to data in multiple, concurrent DBMSs.
·	ODBC is a portable application programming interface (API), enabling the same interface and access technology to be a cross-platform tool.
·	ODBC insulates applications from changes to underlying network and DBMS versions. Modifications to networking transports, servers, and DBMSs will not create problems for current ODBC applications.
·	ODBC promotes the use of SQL — the standard language for DBMSs.
·	ODBC allows corporations to protect their investments in existing DBMSs and to protect developers’ acquired DBMS skills. ODBC also allows corporations to continue to use existing diverse DBMSs, while developing applications using other systems that are more appropriate to the task at hand.
  
How ODBC Works
ODBC defines an API. Each ODBC application uses the same code, as defined by the API specification, to talk to many types of data sources through DBMS-specific drivers. A driver manager sits between the applications and the drivers. In the Microsoft Windows operating system, the driver manager and the drivers are implemented as dynamic-link libraries (DLLs). The following illustration outlines the process.

The application calls ODBC functions to connect to a data source, send and receive data, and disconnect. The driver manager provides an application with information such as a list of available data sources, loads drivers dynamically as they are needed, and provides argument and state transition checking. The DBMS driver, developed separately from the application, sits between the application and the network. The driver processes ODBC function calls, manages all exchanges between an application and a specific DBMS, and may translate the standard Structured Query Language (SQL) syntax into the native SQL of the target data source. All SQL translations are the responsibility of the driver developer.
Applications are not limited to communicating through one driver. A single application can make multiple connections, each through a different driver, or multiple connections to similar sources through a single driver. To access a new DBMS, a user or an administrator simply installs a driver for the DBMS. The user doesn’t need a different version of the application to access the new DBMS. This is a tremendous benefit for end-users, and it also translates into significant savings in support and development costs.
Using ODBC Data in Microsoft Office for Windows 95 Applications
ODBC data is available to Microsoft Office applications in the following ways:
·	In Microsoft Access for Windows 95, by importing from or linking to ODBC data sources using the commands on the Get External Data submenu on the File menu. Microsoft Access can also export to available ODBC data formats using the Save As/Export command on the File menu.
·	In Microsoft Excel for Windows 95, when building Pivot Tables using the Pivot Table command on the Data menu, and with Microsoft Query using the Get External Data command on the Data menu.
·	When creating custom applications in either Microsoft Access or Microsoft Excel using Visual Basic for Applications and Data Access Objects (DAO) code.
  
The next section covers using Microsoft Access to create a client/server application. For more information about using Microsoft Excel and Microsoft Query to access ODBC data, see “Using External Data with Microsoft Excel for Windows 95” later in this chapter.
Reasons to use Client/Server Architecture
The three primary reasons for adopting client/server architecture for database applications are:
·	Enterprise-wide access to corporate information    As computers become smaller, more powerful, and more usable, information is more widely distributed across a corporate enterprise in an increasing number of formats. Client/server technology provides the links to access and manipulate data regardless of its location or storage format.
·	Upsizing multi-user file server database applications    Client/server applications provide improved performance, security, and reliability. Database application solutions can grow and become more complex over time. Client/server architecture provides a way to scale up a database application when it becomes larger and more complex and must support more users and a higher volume of transactions.
·	Downsizing mainframe and minicomputer database applications    The managers and developers of many mainframe database applications move their applications to client/server architecture to take advantage of Graphical User Interface (GUI) processing. Microsoft Access provides an ideal environment for developing user-driven systems. At the same time, Microsoft Access provides many powerful features for interacting with external data sources. Also motivating this change is the reduced cost of new back-end servers. Downsizing, however, is a more difficult and a much slower migration process. As such, the seamless integration from the mainframe world to the client/server world is a priority. When this level of integration is achieved, client/server applications enhance and add value to existing mainframe-based processes.
  
Upsizing a Microsoft Access File Server Application to a Client/Server Application
A high-level summary of steps involved in migrating from a file server to a client/server environment include:
·	Create the server database.
·	Establish your ODBC data source using the ODBC Administrator.
·	Document your existing Microsoft Access database.
·	Export each table to the server database.
·	Add server-based integrity constraints: validation rules, default values, and referential integrity.
·	Add the indexes to the server tables with the necessary attributes.
·	Link the server tables.
  
The remainder of this section explains the above steps in more detail. For full details on these procedures and information about optimizing a client/server application, see Chapter 18 in Building Applications with Microsoft Access for Windows 95.
To ensure your Microsoft Access applications scale up easily to a client/server database, certain practices are recommended:
·	Do not embed spaces in your table names because most servers cannot support them. During export, Microsoft Access will replace spaces with underscores in the name but then references to those fields in queries, forms, reports, expressions, and Visual Basic code will fail.
·	Create a name-mapping query if your application has tables and fields with names with embedded spaces. A name-mapping query is a query saved as the original table name that includes spaces, but it points to the server table without spaces. You can also alias column names using the convention “Field Name: FIELD_NAME” in the query result column field.
·	Be consistent in the use of the case of your object names. Some SQL servers are case-sensitive, but Microsoft Access default behavior is case insensitive.
·	When using programatic access, do not use the Recordset type of table to manipulate remote objects; always use the Dynaset type instead. Tables linked using the Link Tables command automatically use Dynasets.
  
Creating the Server Database
The method for creating a server database depends on the SQL server software you are using. For details, see your SQL server documentation. If you have an existing SQL database you want to use as the basis for your client/server application, you can export or link tables from Microsoft Access after you have defined this database as an ODBC data source.
Defining Your ODBC Data Source
Use the 32bit ODBC icon on the Windows Control Panel to define your ODBC data source. The 32bit ODBC icon will only be available if you installed the SQL Driver when installing Office or Microsoft Access for Windows 95. Before you can specify a data source, you must have the appropriate ODBC driver for your database server installed. You can see what ODBC drivers are available on a computer by double-clicking the 32bit ODBC icon in the Control Panel, and then clicking the Drivers button. The Office Setup program, and the Setup programs for stand-alone versions of Microsoft Access and Microsoft Excel include the Microsoft SQL Server driver and support files for the 32bit ODBC Control Panel option. If the 32bit ODBC icon is not available in the Control Panel, re-run Setup, click Add/Remove, and from the Data Access option, make sure the Microsoft SQL Server Driver option is selected. 
The Data Access option of the Office Setup program also provides a set of additional ODBC drivers. In the Microsoft Access for Windows 95 Setup program, these drivers are called the Microsoft Office Desktop Drivers. These drivers are not used by Microsoft Access itself which uses its own built-in drivers, but can be used by other programs that support ODBC, such as Microsoft Excel and Microsoft Query, to use data in the following formats:
·	Microsoft Access
·	Microsoft Excel
·	Microsoft FoxPro
·	dBASE
·	Paradox
·	Text (fixed-width and delimited text files)
  
If you are using an SQL database server other than Microsoft SQL Server, contact the vendor of that product to find out about the availability of an ODBC driver for that product. ODBC drivers are also available for data formats other than SQL servers. For example, there is an ODBC driver for Lotus Notes databases. Contact the vendor of the product whose data you want to access for information about the availability of an ODBC driver.
  
Important   Microsoft Office for Windows 95 applications can only use 32-bit versions of ODBC drivers. If a previous version of a Microsoft Office application, such as Microsoft Access 2.0, was installed on a computer, older 16-bit versions of ODBC drivers may still be present. If you want to use the ODBC drivers available with Microsoft Office for Windows 95 applications, re-run Setup and install the drivers you need. Similarly, other applications written for Windows 3.x may have installed older 16-bit versions of ODBC drivers. Contact the vendor of the product whose data you want to access for information about the availability of a current 32-bit version ODBC driver.
  
Documenting Your Existing Microsoft Access Database
Indexes, validation rules (also referred to as business rules, domain integrity rules, or database-specific rules), default values, and referential integrity rules are not created when Microsoft Access exports tables to a client/server database. After exporting, you need to define the indexes, validation rules, and default values on the server tables themselves. If permissions vary for users of the database, you’ll need this information, too. You can print a very comprehensive list of the properties of the tables in your .mdb file by opening the database with Microsoft Access and then using the Documentor command on the Analyze submenu of the Tools menu.
Exporting Microsoft Access Tables to the Server Database
Creating the structure of a complex, multi-table, client/server database can be a tedious and time-consuming process. Microsoft Access table export features can speed up this process greatly. Export each table to the server database, using the Export/Save As command on the File menu. 
There are trade-offs to consider when exporting data. Microsoft Access exports each row one row at a time. This ensures that your exported data adheres to all the server-based rules, but is significantly slower with very large tables than using server-based, bulk-copy routines.
If your tables contain a few thousand records or less, it is usually faster to export the tables from the Microsoft Access database to the server database, rather than using bulk-copy programs, such as BCP for SQL Server, with text files. If you do use a batch copy program to load your tables on your server, you can test data type and field size consistency before running the batch copy program by exporting at least one record from each table to the server using Microsoft Access.
Most migrations to client/server operation are done in two phases: test and production. To limit the number of records used for the test phase, write a select query in Microsoft Access and then export data from that query.
Adding Server-Based Validation Rules
Validation rules aren’t exported with a table. You can create triggers or rules on the server table that enforces your rules, or you can define form-level validation rules in your Microsoft Access forms instead. Using form-level rules is easier, but not as reliable because invalid entries are rejected only by the form, not by the server table itself. A trigger is a piece of code residing on the server that executes an SQL statement prior to the occurrence of a specified event, such as INSERT, DELETE, or UPDATE. If you’re using a server-based trigger, be aware that many Visual Basic functions, such as the DatePart or Format, may have no equivalent on your server.
Adding Default Values and Enforcing Referential Integrity
Most client/server DBMSs provide a default value property. Otherwise, you need to use stored procedures to set default values for fields whose value is not supplied during the append process. If you need to emulate the Required property of fields in Microsoft Access tables, you can use the NOT NULL command in the definition of your SQL table. If the server database does not support ANSI SQL reserved words, you’ll need to write stored procedures to enforce referential integrity and perform cascading updates and deletions. None of the rules and stored procedures you create will be visible to Microsoft Access; if your applications violate the rules, your application will receive an error message from the server.
Adding Indexes
Add the indexes to the server tables with equivalent attributes to those in the Microsoft Access database, for example, PrimaryKey, No Duplicates, or No Nulls. Microsoft Access cannot update a table that does not have a unique index.
In Microsoft Access 2.0 or later, dynaset-type record sets support server-based primary key generation from triggers. In earlier versions, as the primary key was generated during an insert, the record set cursor would act as if the record has been deleted because it no longer was in the same location. Microsoft Access now re-fetches the record, keeping the record set up to date. This is particularly significant because many developers use the convenient AutoNumber field (called a Counter field in previous versions) to generate their primary keys. The equivalent of the Microsoft Access AutoNumber field data type seldom is found in client/server DBMSs, yet it can be critical to your application.
This improvement allows you to create an INSERT trigger on the server table that increments the integer value of a field each time a new record is appended to the table. The Transact-SQL statement to create the equivalent of an AutoNumber field is:
  
CREATE TRIGGER add_customer_id ON dbo.customers
FOR INSERT AS 
UPDATE dbo.customers
SET inserted.Customer_ID = (SELECT MAX(Customer_ID)
FROM dbo.customers) + 1
WHERE dbo.customers.customer_ID IS NULL
  
When you use a trigger to create the AutoNumber field equivalent, you will not see the generated value in a bound control until you complete the appending process for the record.
Linking Server Tables
Use the Link Tables command on the Get External Data submenu of the File menu to link tables in the server database. When you link a table, Microsoft Access stores a copy of the table’s structure in your Microsoft Access database’s system tables. This allows you to build queries, forms, and reports as if the linked table is part of your database.
After linking, relationships between tables need to be established using the Relationships window. This establishes the default join conditions and types used when building new queries.
Any operation in Datasheet view that is permissible for a native Microsoft Access table can generally be performed for tables linked by ODBC. In Design view, you can set the values of the Format, InputMask, and Caption properties. All other properties of linked tables are read-only.
Renaming Linked Tables
When Microsoft Access links a remote table, it prefixes the default table owner ID of SQL Server to each table name. The period separator between the owner ID and the table name is replaced by an underscore, because periods in table names are not permitted by Microsoft Access. By doing so, the names of linked tables no longer correspond to the original table names in your .mdb file. The simplest way to correct this is to rename your tables to their original names after linking.
Using External Data with Office for Windows 95
This section explains how to use external data with Microsoft Access for Windows 95 and Microsoft Excel for Windows 95.
Using External Data with Microsoft Access for Windows 95
Microsoft Access is extremely flexible in its ability to handle data from a variety of sources. External data falls into two categories: Indexed Sequential Access Method (ISAM) and Open Database Connectivity (ODBC). The ISAM data sources are the traditionally IBM PC-based database formats. These include Microsoft FoxPro, Paradox, Microsoft Access, and others. The ODBC data sources are typically SQL (Structured Query Language) server tables, such as Microsoft SQL Server tables; however, Microsoft Access can use other ODBC data sources as long as a 32-bit, Level 1-compliant ODBC driver is installed for that data source.
Microsoft Access can either import or link external data. Importing reads the external data and creates a new table in the current Microsoft Access database. The original data is unchanged. Linking leaves the external data in its current location and format, and stores a link to that data in the current Microsoft Access database. When a table from another database is linked, it performs like a native, local table. Users can create queries, forms, and reports that use the external data, combine the external data with the data in Microsoft Access tables, and even view and edit the external data while others are using it in the original application. It makes sense to use this approach as an alternative to importing if the external data you want to use is also being updated by software other than Microsoft Access. 
Even if all the data you want to use is in Microsoft Access format, you might find it advantageous to link to external data. By splitting the application (forms, reports, queries, temporary tables) from the rest of the data, you can ease the support burden of distributing your application. Additionally, network traffic is reduced because forms, reports, and queries are run locally on each workstation instead of across the network as when the entire database is run from a shared location.
There are two methods of accessing external data: using the commands on the Get External Data submenu on the File menu, or using Visual Basic for applications code.
External Data Sources
Microsoft Access can use data from any of the following external data sources:
·	Databases created by applications that use the Microsoft Jet database engine (Microsoft Access, Microsoft Excel, Microsoft Visual Basic)
·	Open Database Connectivity (ODBC) databases such as Microsoft SQL Server 4.2 and higher
·	Paradox 3.x, 4.x, and 5.x
·	Microsoft FoxPro 2.0, 2.5, and 2.6 (and 3.0, to import but not link)
·	dBASE III, dBASE IV, and dBASE 5.x
·	Lotus WKS, WK1, and WK3 spreadsheets
·	Microsoft Excel 3.0, 4.0, 5.0, and 7.0 worksheets
·	Text files
  
To access external data, applications that use the Microsoft Jet database engine use one of several installable ISAM drivers or the Microsoft SQL Server driver. If you chose Typical installation when you installed Microsoft Access, you don’t have these drivers installed. To install the appropriate driver for the external database you want to access, run Setup again, click the Add/Remove button, select the Data Access check box in the Options list box, and then click Change Option and select the drivers. If you haven’t installed Microsoft Access and want to make sure you have the correct drivers installed, run Setup, click the Custom button, select the Data Access check box in the Options list box, and then click Change Option and select the drivers. The only ODBC driver that is supplied with Microsoft Access is the Microsoft SQL Server driver. To access ODBC data other than Microsoft SQL Server tables, you must obtain a 32-bit version of the appropriate ODBC driver from the vendor of that data format, and install that driver.
Network Access Requirements
To link or directly open an external table on a network, you must be able to connect to the network and have use of:
·	The server and share (if applicable) on which the external database is located. Server and share access are established through network permissions. For information about setting up network permissions, see your network product manuals.
·	The external table. Table access permissions, if any, are established using the security features of the external database. Depending on how security has been defined, you might need to get the appropriate passwords, or you might need to have a network administrator grant you the appropriate permissions to use the external table. For information about setting up access permissions, see your external database product manuals.
  
When specifying the database name for a database on a network drive, you can either:
·	Indicate a fully qualified network path (if your network supports it) in the format \\server\share\path. For example:
  
\\FOXPRO\DATA\AP
  
·	Establish a connection to the network drive first, and then specify the path using the network drive letter instead of the server and share name. For example, if you use drive F: to connect to \\FOXPRO\DATA, you would specify the database path for the AP database on that share as follows:
  
F:\AP

Performance Guidelines
Although you can use external tables just as you use Microsoft Access tables, it’s important to keep in mind that they’re not actually in your Microsoft Access database. As a result, each time you view data in an external table, Microsoft Access retrieves records from another file. Performance is optimal if you link tables instead of opening them directly, and if you retrieve and view only the data you need. For example, it’s a good idea to use restrictive queries to limit the number of returned records so you don’t have to scroll up and down unnecessarily.
For more information about improving performance, see “Optimizing Microsoft Access for Windows 95” in Chapter 11.
Windows Registry Settings
When you install Microsoft Access or external database drivers, the Setup program writes associated entries to various keys in the Windows Registry. The Setup program writes a set of default values for each installed ISAM engine in a subkey of the Hkey_Local_Computer\Software\Microsoft\Jet\3.0\Engines key. It also writes a set of host-application specific values for each ISAM engine in the Hkey_Local_Computer\Software\Microsoft\Access\7.0\Jet\3.0\Engines key, and in a similar key for other host applications that use the Jet database engine. These multiple registrations allow each host application to run a separate instance of the Jet database engine. If a host-specific registration omits particular values, these settings default to the values registered in the Microsoft\Jet\3.0\Engines key.
Another set of registration settings are provided in the Microsoft\Jet\3.0\ISAM Formats key of the Windows Registry. This key contains a subkey for each of the specific data formats supported by a particular ISAM engine.
Although the Setup program writes intelligent defaults for the Windows Registry entries, your particular environment or preferences might require you to change entries. For information about all registry entries, see the Microsoft Access section of Appendix B, “Registry Keys and Values.” 
  
Note   When you change your initialization settings, you must quit the application and then restart it using the Microsoft Jet database engine for the new settings take effect.
  
Case Sensitivity
Unlike searches on databases that use the Jet database engine, searches on external databases may be case-sensitive. However, searches aren’t case-sensitive in the following cases:
·	For Paradox data, if the CollatingSequence entry in the Jet\3.0\Engines\Paradox key of the Windows Registry is set to International, Norwegian-Danish, or Swedish-Finnish.
·	For FoxPro or dBASE data, if the CollatingSequence entry in the Jet\3.0\Engines\Xbase key of the Windows Registry is set to International.
·	For ODBC data, if the server is configured not to be case-sensitive.
  
In addition, if a search is made across more than one data source type, the case sensitivity depends on the collating sequences of the databases in which the query is stored.
Unsupported Objects and Methods
When using Visual Basic for applications code, some data access objects and methods are intended for use only on databases created using the Microsoft Jet database engine, such as databases created by Microsoft Access, Microsoft Visual Basic, and Microsoft Excel. These data access objects and methods aren’t supported for use with external databases in other formats. Unsupported data access objects include:
Container
Document
QueryDef
Relation
Unsupported methods include:
CompactDatabase
CreateDatabase
CreateField (if the table has existing rows)
CreateQueryDef
RepairDatabase
In addition, the following transaction processing methods are supported only if the external database supports transactions:
BeginTrans
CommitTrans
Rollback
Troubleshooting
The following information addresses problems you may encounter when accessing an external data source.
Connection Problems
If you have trouble connecting to an external data source, first check your connection to the network. Make sure you have access to:
·	The server and share (if applicable) on which the external database is located.
·	The external table.
  
Other things to check include the following:
·	Can you connect using another product or a different user account and password?
·	Have you exceeded the connection limits on the server?
·	Does the server have enough space?
·	Does the connection information match the case sensitivity of the server?
  
If you’ve checked the items in the preceding lists and you still cannot connect, contact your external database vendor.
Temporary Space
When you query a database, Microsoft Access creates temporary indexes on your local hard disk, even if the database is on an external network device. Temporary space requirements can vary from a few thousand bytes to several megabytes, depending on the size of the external tables being queried.
Temporary space is allocated from the folder indicated by the TEMP environment variable, typically the \Windows\Temp folder. If your system has not defined a TEMP environment variable, the current Microsoft Access root folder is used. If the TEMP environment variable points to an invalid path or if your local hard disk doesn’t have sufficient space for these temporary indexes, your application may perform unpredictably if Windows and Microsoft Access run out of resources.
Using External Data with Microsoft Excel for Windows 95
In Microsoft Excel for Windows 95, your users can also use data from external sources. The Microsoft Query application and the Microsoft ODBC Functions Add-in assist you in constructing SQL instructions to extract and summarize information from a variety of database formats. Using the PivotTable Wizard, you can set up complex database queries and build detailed summary reports without having to write any SQL code. Using the Template Wizard with Data Tracking, you can create a template to export data to an external database.
There are five ways to use external data with Microsoft Excel:
·	Microsoft Query    This is a graphical application used to retrieve and organize data from a variety of data sources. Use it if you want to display and manipulate data before you bring it into Microsoft Excel. You can also initiate a Dynamic Data Exchange (DDE) conversation between Microsoft Excel and Microsoft Query using Visual Basic for applications to create custom applications that use Microsoft Query to access external data. For example, you can send DDE commands to Microsoft Query using the LinkExecute method in Visual Basic for Applications code.
·	The Microsoft Query Add-in    This is an add-in macro that adds the Get External Data command to the Data menu so that you can run Microsoft Query from within Microsoft Excel. It is possible to use Microsoft Query as a stand-alone application (by running the Msqry32.exe program), or by using DDE commands in Visual Basic for applications code; however, the most common method is using the Get External Data command in Microsoft Excel.
·	Microsoft Open Database Connectivity (ODBC) Functions Add-in    This is used to retrieve data directly from external data sources using Microsoft ODBC. This add-in provides Data Access Objects (DAO) functions that are used in Visual Basic for applications code to create custom Microsoft Excel applications that access ODBC data sources. These functions interact directly with database drivers without using Microsoft Query.
·	The PivotTable Wizard    This is an interactive worksheet table you use to summarize large amounts of data. It is called a pivot table because you can rotate its row and column headings around the core data area to give you different views of the source data. The PivotTable Wizard uses Microsoft Query to access external data and create a dynamic crosstab table of the results.
·	The Template Wizard with Data Tracking Add-in    This creates a template and a database from a Microsoft Excel workbook. You select the cells that will be used as the template and the wizard links them to a database in the format you select. After the wizard creates the template, you can share the template with users in a workgroup to update a shared database. Each time users enter data in the template, it will be exported to the database.
  
The types of data you can retrieve depend on the open database connectivity (ODBC) drivers you install to work with Microsoft Query and Microsoft Excel. An ODBC driver is a system dynamic-link library (DLL) that allows ODBC-enabled applications such as Microsoft Query and Microsoft Excel to access specified data sources and retrieve data created in another format, such as dBASE. For more information about ODBC and how it works, see “ODBC and Client/Server Operations” earlier in this chapter.
You can access and retrieve data using drivers for the following types of data, which are available in Microsoft Excel for Windows 95:
·	Microsoft FoxPro (versions 2.0 and 2.5)
·	Microsoft Access (versions 1.x, 2.0, and 7.0)
·	Paradox (versions 3.x, 4.x, and 5.x)
·	dBASE (versions III, IV, and 5)
·	Microsoft SQL Server (versions 4.2 and higher)
·	Microsoft Excel (versions 3.0, 4.0, 5.0, and 7.0)
·	Text (fixed-length and delimited formats)
  
If you performed a Compact or Typical installation, the ODBC drivers listed will not be available. Re-run the Microsoft Office or Microsoft Excel Setup program to install ODBC drivers. You can also use other 32-bit, Level-1 compliant ODBC drivers that are not supplied with Microsoft Office to access additional data sources. For information about whether a 32-bit, Level-1 compliant version ODBC driver is available for the data source you want to access, contact the vendor of that data format. For information about the installation of drivers other than those that are supplied with Microsoft Office, see the documentation for that driver.
Workgroup Features for Microsoft Access
Microsoft Access workgroup features fall into two areas: Security Administration and Multiuser Settings. The section on Security Administration covers the methods of regulating access to the information and design of a database. The section on Multiuser Settings covers how Microsoft Access works when databases are shared between members of a workgroup, such as how conflicts are handled if two users try to edit the same record at the same time.
Security Administration
Microsoft Access security is not used exclusively in workgroup situations. For example, security can be used to control access to data in a database that resides on a single computer and is not shared by any other user. However, the most common application is in workgroup situations.
The first section describes the difference between the two kinds of security Microsoft Access provides, how to use the new database password feature, and some concerns about using it in a multiuser environment. This is followed by in-depth information about the Microsoft Access user-level security model, how to use the User-Level Security Wizard, and how to address common security scenarios. The final section describes other security enhancements added to Microsoft Access for Windows 95.
User-Level Security vs. Share-Level Security
Microsoft Access security supports two kinds of security: user-level security and a simple form of share-level security (defined later in this section). The kind of security you use depends on your requirements.
User-Level Security
Unlike most other personal computer-based database programs, Microsoft Access provides user-level security as its primary form of security. In a user-level system, users must have security accounts defined before they can use secured databases. Users’ identities are verified when they start Microsoft Access by logging on with a password. Database administrators or object owners grant permissions, such as Read Data or Modify Design, to specific users and groups to regulate access to specific objects. Different users can have different permissions for the same object, hence users or groups can have different user-levels with respect to that object.
By contrast, in share-level security systems, passwords are associated directly with objects, not with users or groups. Passwords act as gateways to the objects, and determine the kind of actions that can be performed. Any user who knows a particular password can perform the actions that password allows.
For example, suppose you have a Salary table, and that you have two groups of users on your system: Managers, who you want to allow to update the table, and Payroll personnel, who you want to allow to view but not update the table. In a user-level system, such as Microsoft Access, you assign update permissions to the Managers group and read permissions to the Payroll group. You then make sure that the users logging onto your system are enlisted in the appropriate groups. Users can manage their own passwords, and their passwords are only used to verify their identity when logging on, rather than having any direct connection to their permissions.
To establish the same kind of security using a share-level security system, you would assign two passwords to the Salary table: a read-only password and a read-write password. You would then tell all managers the read-write password, and all the members of your payroll department the read-only password. Whenever a user needs to access the table, the user enters that password and is granted the kind of access provided by that password.
If you’ve never built or administered a user-level security system before, the important thing to remember is that there’s no such thing as a permission for an object that exists all by itself — permissions for objects are always granted to users and groups. In a Microsoft Access database, it doesn’t make sense to say, “the Salary table has Read Data permissions” because no user or group is specified. It does make sense to say “the Managers group has Read Data permissions for the Salary table.”
Share-Level Security: Database Password Protection
For many users and situations, user-level security in Microsoft Access is too complex and provides more control than is required. There are many situations where users would prefer to simply assign a single password to control who can open a database. This simple form of share-level security was added to Microsoft Access for Windows 95. Whenever the database is opened after assigning a database password, the Password Required dialog box is displayed; if the user knows the password, the database will be opened. Only one password can be assigned to open the database, and no distinction can be made between read/write versus read-only access. If you want to do more than just limit who can open the database, user-level security is required.
If user-level security has been defined and a database password is added, all user-level security remains intact. That is, user-level permissions will still be required to perform any actions on objects. Adding a database password in addition to user-level security does not provide any added security, and is not really the way the feature is intended to be used. It is meant to be a simple alternative to user-level security.
To define a database password, open the database. On the Tools menu, point to Security and click Set Database Password. Supply and verify the password in the dialog box provided. After it is defined, the password is encrypted and stored with the database to which it applies. When a database password is set, all users must supply a password to open the database. Any user who knows the password can change the password or remove it. 
  
Note   A password can be set when the database is opened in shared mode (the default mode), even when other users have the database open. However, in this case, the new password won’t affect those users until they close the database and open it again. If you work in an environment where users don’t turn off their computers at night, they may never close the database. If this is the case, open the database in exclusive mode (set the Exclusive check box in the Open dialog box) so you can ensure that no one is using the database when you add the database password. After setting the password, close the database to make it available again.
  
After a password is set for a database, the menu command changes to Remove Database Password. Selecting this option displays the Remove Database Password dialog box. Entering the correct password sets the password property to null which turns off share-level security for the database.
Setting a database password only controls whether a user can open the database. If you need to maintain security for individual objects within the database, you need to define user-level security instead. 

Caution   If any user sets a password and then loses it or forgets it, no user can gain access to the database no matter what their user-level authority is. The form of encryption Microsoft Access uses to hide the database password is extremely secure and is virtually impossible to break. For this reason, make sure that any user that sets a database password, keeps a copy of the password in a secure off-site location.
To provide strict control over who can set a database password, use the User-Level Security Wizard to define user-level security as described later in this section, and then, for users or groups who you don’t want to set database passwords, remove the Administer permission on the Database object. To prevent a database from being password-protected, you must remove the Administer permission for that database. 
In a more casual environment, you can prevent a database password from being set without setting up a complete user-level security system that requires logging on. To do this, use the User And Group Permissions command on the Security submenu to remove Administer permission for the Admin user and the Users group (and any other users or groups that may have been defined). When defined like this, it is possible for any user to use the User And Group Permissions command to getback the Administer permission, but well-meaning users would have no reason to do so.

User-Level Security Model
The information in this section covers the Microsoft Access user-level security model in detail. 
When Do I Need User-Level Security?
Three primary reasons to use user-level security are:
·	To prevent users from inadvertently breaking applications by changing code or objects on which the application depends.
·	To protect sensitive data in a database.
·	To protect the intellectual property of developers’ code in Microsoft Access applications.
  
How Does User-Level Security Work?
User-level security in Microsoft Access functions as follows: Administrators or object owners grant sets of permissions to specific users or groups for specific database objects. The set of permissions granted to the user or group determines that user’s or group’s user-level which determines how that user or group can access that specific object. When a user starts Microsoft Access in a secure environment, the user logs on, usually with a password. The password verifies that the user is who the user claims to be. Microsoft Access then checks and stores in memory a record of all the groups to which that user belongs. Every time the user tries to perform an action on an object, such as open a form, browse a table, or modify a query, Microsoft Access checks to see if the user, or any of the groups to which the user belongs, has the necessary permissions to do so. If so, Microsoft Access performs the action, if not, Microsoft Access displays a message that the user doesn’t have the permissions to perform the requested operation, and the operation fails.
When is User-Level Security Turned On?
Microsoft Access user-level security is always turned on — that is, every time a user performs any action, Microsoft Access first checks to make sure the user has permissions to perform that action. However, most Microsoft Access users never realize they are logging on and never see a security-related message. The illusion that user-level security is not turned on is created by granting full permissions for all objects, by default, to the Users group, which includes all users. Then each user is automatically logged on under a default user account, named Admin, without displaying a logon dialog box. Until a developer or administrator takes explicit action to expose the security subsystem, most users will never notice that it exists. This allows Microsoft Access to be extremely secure, with no backdoor modes of operation, but still keeps security virtually invisible to users who don’t need it. This can also be used to implement security without explicitly requiring users to log on. For more information, see “Securing Your Database Without Requiring Users To Log On” later in this section.
Where is User-Level Security Information Stored?
Microsoft Access stores its security information in two different places. User and group information is stored in the workgroup information file that was current when those users and groups accounts were defined using the User And Group Accounts command on the Security submenu of the Tools menu. An administrator or user specifies the current workgroup information file before starting Microsoft Access by running the Workgroup Administrator application. The Workgroup Administrator can also be used to create new workgroup information files. When Microsoft Access 7.0 starts, it determines the current workgroup information file by reading the SystemDB value in the Windows 95 Registry in the \\Hkey_Local_Computer\Software\Microsoft\Access\7.0\Jet\3.0\Engines\Jet key. For Microsoft Access 2.0, this is determined by reading the SystemDB value in Msacc20.ini.
A workgroup information file is a database that stores user and group account names, which users belong to which groups, logon passwords for individual users (encrypted), and the internal Security ID (SID) for each user and group. The options available using the User And Group Accounts command change this data in the workgroup database. The preferences users set with the Options command on the Tools menu are stored for each user account. A single workgroup information file can be used to store the user and group account information used to access as many databases as you want.
The default workgroup information file that is created by Setup when installing Microsoft Access is named System.mdw. An identical copy of the default file can be recreated at any time by re-installing Microsoft Access and providing the same name and company name that was used for the original installation. If you need to ensure the absolute security of your system, you should create a new workgroup information file before defining security accounts.
All the permissions that users and groups have for the objects in a database are stored in the database itself. After a user’s identity and group membership have been established by checking the logon strings against data in the workgroup information file, all permission checking is done against system tables within the user database. The User And Group Permissions command on the Security submenu of the Tools menu affects only data in the open database, not the workgroup information file. Permission and ownership information set by running the User-Level Security Wizard affects only the new database created by that process.
Logging On
Each user and group account has an associated Security ID (SID). The SID is a computer-generated, non-readable binary string that uniquely identifies the user or group. When a user logs on, Microsoft Access looks in the MSysAccounts table of the workgroup information file for a user of the same name, which is case insensitive. If a user with the same name is found, it then validates the password which is case sensitive. If the password matches, the SID of the user is retrieved and saved in an internal structure. The password is only used to validate the user when logging on. It has no other effect on security.
By default, as Microsoft Access starts up it first attempts to log on as the default user Admin with a blank password. If this logon attempt fails, the Logon dialog box is displayed. If a user name and password is specified on the command line (using the /User and /Pwd command line options), Microsoft Access first tries to log on using that user name and password. However, entering a user name and password from the command line is not a recommended practice as it would compromise the security of the system; it is generally used as a convenience when testing a secured database. After a user logs on, the user’s SID is retrieved. Then the SIDs of all groups to which that user belongs are retrieved and saved in the same internal structure. These SIDs are used for all subsequent security operations within Microsoft Access.
Microsoft Access for Windows 95 has added the ability to integrate with Windows 95 password caching policies. For more information about caching policies, see “Password Caching” later in this chapter.
The following flowchart represents the logon sequence from the first time a user installs Microsoft Access

Users and Groups
Each user can belong to one or more groups. Users and groups share the same namespace; you cannot have both a group and user with the same name. User and group accounts are not stored in individual databases; they are stored in the workgroup information file. For more information about workgroup information files, see “Where is User-Level Security Information Stored?” earlier in this chaper.
Each user and group account is uniquely identified by a Security Identifier, or SID. SIDs are the only user information that Microsoft Access checks when deciding whether or not a user has permissions to perform an operation on an object. When you create a new user or guest account, you are prompted for a user name, and a Personal ID (PID). Note that the PID is not the password. The user name and PID are sent to an encryption procedure that generates the SID for that account. The PID is a variable length, alphanumeric string. The SID that Microsoft Access generates from the user name and PID is a 128-bit number. If you send the same two keys again to the encryption program, you will get the same SID. This gives you the ability to recreate user accounts if your system database becomes corrupted.
Microsoft Access defines one default user: the Admin user account, and two default groups: Users and Admins. Understanding how the SIDs of these default accounts are generated helps you understand how the security works.
Admin User
The Admin user is the default user account. If someone is using Microsoft Access and not logging on, they are using the Admin account. The Admin account has no particular administrative abilities. because most users are logged in as the Admin user without ever knowing it, and because all users by default have permissions to objects they create, any objects that are owned by the Admin user or to which the Admin user has explicit permissions are unsecure. You can think of the Admin account as the DefaultUser account, or for those familiar with Windows NT security, as the Everybody account.
The Admin user’s SID is identical across all installations of Microsoft Access and any other applications that use the Microsoft Jet Database Engine to access .mdb database files, including applications such as Microsoft Visual Basic and Microsoft Excel. Even if no one in a workgroup is using the Admin account because a password has been set for it, all objects owned by the Admin user, or to which the Admin user has explicit permissions are still open to anyone using their own copy of Microsoft Access or another application that uses Microsoft Jet. So make sure the Admin user has no explicit permissions and owns no objects. The easiest way to do this is to use the the User-Level Security Wizard to secure a database.
By default, the Admin account doesn’t receive any permissions for new objects. However, when any user creates an object, that user’s account is automatically granted full permissions for this object, and becomes the owner of that object. Because all users in unsecured environments log in as Admin, the Admin account usually owns a lot of objects and has a lot of permissions. When you need to secure your database, use the User-Level Security Wizard to remove those permissions.
Users Group
The Users group is the default group. All users belong to the Users group. Any permissions that are assigned explicitly to the Users group are available to all users in all installations of Microsoft Access. If you ever need to unsecure an object, simply assign permissions for that object to the Users group.
The Users group’s SID is identical across all installations of Microsoft Access and any other applications, such as Microsoft Visual Basic and Microsoft Excel, using the Microsoft Jet Database Engine to access .mdb database files.
By default the Users group gets full permissions on all newly created objects. This is the main mechanism that Microsoft Access uses to hide security from the majority of users who don’t need it. The easiest way to remove this permission from all objects in a database is to use the User-Level Security Wizard. 
Admins Group
Users who are members of the Admins group are the true administrators of a workgroup. They manage user and group membership, and have the power to clear users’ passwords. There must always be at least one member of the Admins group.
The Admins group of the workgroup information file in use when the database was created gets full permissions by default on all new objects in a database. The Admins group’s right to change permissions cannot be revoked through the Microsoft Access user interface. Even if you uncheck the Administer privileges check box in the Permissions dialog box for the Admins group for an object, the permission remains. It is therefore very important to know and keep track of which workgroup information file was in use when the database was created.
Because the Admins group is invested with superuser capabilities, understanding how the Admins group SID is created is key to understanding the security model. In Microsoft Access 2.0 and 7.0 the Setup program uses the user’s name and the company name as seeds for the Admins group’s SID. Because these two strings are available from the Help menu, it is critical that users implementing security use the Workgroup Administrator to create a new Admins group with a secure SID.
The Workgroup Administrator will prompt for a Name, a Company Name, and a Workgroup ID. It uses these strings as encryption seeds to generate the Admins group SID. It is very important to record these three case sensitive strings in a secure, off-site location. If the workgroup information file is ever destroyed or corrupted beyond repair, you can generate a new Admins group with an identical SID by running the Workgroup Administrator and entering the same exact strings. If you are a member of this re-created Admins group you will be able to grant yourself permissions on all objects that were created when the old workgroup information file was in effect. 
Summary of Default User and Group Accounts
The SID of the Admins group account is unique across workgroups, but the SIDs of the other two default accounts, the Admin user and the Users group, are identical across all installations of Microsoft Access. Permissions assigned to the Admins group are secure, but permissions assigned to the Admin user or the Users group are available to anyone with a copy of Microsoft Access and any other applications using the Microsoft Jet Database Engine to access .mdb database files, such as Microsoft Visual Basic and Microsoft Excel.
Creating Your Own Users and Groups: SIDs, PIDs, and Passwords
Members of the Admins group create new user and group accounts. They determine which users are members of which groups. Microsoft Access identifies each user by the user’s SID.
Because each user account is identified by its SID, it’s important to record user and group names and their PIDs in a safe place. If you ever need to recreate the workgroup information file, you will need the name and PID of each user and group. If you try to recreate a user or group with the user name or group name and a different PID, you will get a different SID and thus not have the access privileges the user name or group previously had. 
After a user account has been created, users can modify their own passwords. Passwords have no effect on the user’s SID or permissions. They simply identify the user account to Microsoft Access. There is no built-in password aging in Microsoft Access, although it is possible to write a subroutine to monitor password aging with Visual Basic for applications and Data Access Objects (DAO) code. 
The easiest way to administer permissions in a workgroup is to create new groups and assign permissions to the groups, rather than to individual users. Then you can change individual users’ effective permissions by adding or deleting the users from the groups. Most workgroups only require three or four groups to give them the permission control that they need, and it’s much easier to maintain permissions for three or four groups than for fifty or a hundred users. 
The CurrentUser Function and Duplicate User Names
The CurrentUser function in Visual Basic for applications returns the name of the current user. This is not the same as the SID. It is possible for two users in different Workgroup information files to have the same user name but different SIDs, because when their accounts were created, different PIDs were fed to the SID generating program and different SIDs were created. Watch out for this problem if you using the CurrentUser function to log user activity. 
Permissions
Explicit permissions are those permissions granted directly to a user; no other users are affected. Implicit permissions are those permissions granted to a group; all users who are members of a group get the permissions assigned to that group.
When a user attempts to perform an operation on an object, that user’s security level is determined by the least restrictive of the permissions explicitly assigned to that user and the permissions implicitly assigned to the groups to which that user belongs. For example, if User1 has no explicit permissions on the Orders table but belongs to the Clerks group, which has Read Data permission on the Orders table, User1 will be able to read the data in the table. If User1 is removed from the Clerks group and doesn’t belong to another group with permissions on the Orders table, User1 will be denied any access to the Orders table.
Permissions can be changed for an object by:
·	Members of the Admins group of the workgroup information file in use when the database was created.
·	The owner of the object.
·	Any user who has Administer permission on the object.
  
Even though users may not currently be able to perform an action, they may be able to grant themselves permissions to perform the action. This is true if the user is a member of the Admins group of the workgroup information file in use when the database was created, or if the user is the owner of an object.
The user who creates an object is the owner of that object. You can change the ownership of an object using the Users And Group Permissions command on the Security submenu of the Tools menu, or you can re-create the object. To re-create the object, you do not have to start from scratch. You can make a copy of the object, or import it or export it to another database. 
  
Note   This procedure doesn’t change the ownership of queries whose RunPermissions property is set to Owner’s. You can change ownership of a query only if you are the query owner, or if its RunPermissions property is set to User’s.
  
If you want to secure an entire database, you can create a new database, which establishes your ownership of the database itself, and then import all of the objects into the new database which transfers the ownership of all of the objects. This is part of the process that the User-Level Security Wizard performs for you.
Viewing Permissions
You can view a user’s permissions for an object using the Tools|Security|User And Group Permissions command. However, when doing so, you only see the user’s explicit permissions. To view a user’s implicit permissions, you must view the permissions of each group to which the user belongs. Using the Microsoft Access user interface, there’s no way to see the union of all the user’s explicit and implicit permissions for an object. In other words, you cannot select a user and see in one place whether that user can perform an action on an object. You need to look at the user’s account and the groups to which the user belongs as well. You can print a report of all the users and the groups to which each user belongs using the Print Users And Groups button in the User And Group Accounts dialog box.
Database-Level Permissions
In Microsoft Access, there are three database level permissions: Run/Open, Open Exclusive, and Administer. 
Run/Open Permission: Keeping Users from Opening a Database
The Run/Open permission gives you a simple, clean way to lock unauthorized users out of a database entirely. However, users cannot be prevented from creating new objects in a database that they can open. 
Open Exclusive Permission: Keeping Users from Opening in Exclusive Mode
The Open Exclusive permission is used to prevent users from locking each other out of a shared database by opening it for exclusive access. This is less of a problem when using Microsoft Access for Windows 95 because it opens databases in shared mode by default, whereas previous versions open databases in exclusive mode by default. However, this may be a significant issue if some of your users are still using previous versions of Microsoft Access and are sharing those databases with Microsoft Access for Windows 95 users. In either case, you can prevent users from locking other users out of a database without setting up a complete security system requiring users to log on. To do so, revoke the Open Exclusive permission for all users and groups, including the Admin user and the Users group. After this is done, users starting Microsoft Access under the default Admin account won’t be able to open the database exclusively. Microsoft Access will detect that they don’t have this permission, and will automatically open the database as shared. If you don’t choose to set up users and groups with logon IDs, it is possible for users to use the User And Group Permissions command and grant themselves this permission, but well-meaning users would have no reason to do so.
Administer Permission: Keeping Users from Setting a Database Password, Replicating a Database, or Changing Startup Properties
In Microsoft Access for Windows 95, the Administer permission has been extended to apply to the database object. In previous versions, the Administer permission only applies to objects within the database. When applied to the database object, the Administer permission controls access to the following areas:
·	Setting a database password
·	Replicating a database
·	Startup properties and the AutoExec startup macro
  
By default, all users (the default Admin user and all members of the default Users group) have the Administer permission for the database. You need to set up user-level security to revoke this permission. You can prevent users from setting a database password and locking out other users by revoking this permission. For more information about database passwords, see “Share-Level Security” earlier in this chapter. The Administer permission is also required to convert a database for replication. For information about database replication, see Chapter 16, “Microsoft Access Database Replication.” Finally, the Administer database permission allows the user to change the startup properties set using the Startup command on the Tools menu, such as the startup form or the Use Access Special Keys check box that controls special keys such as the ability to hold down the SHIFT key to bypass startup properties and the AutoExec macro. The Administer permission also controls whether a user can edit the AutoExec startup macro. Additionally, you can grant the Administer permission for the database object, and revoke the Administer permission for all objects within the database, to a user. This allows that user to set these administration-level properties without assigning that user to the Admins group, which would confer full permissions on all objects.
Ownership
Ownership is an important part of the Microsoft Access security model. The SID of the user who creates an object is the owner of the object. The object owner always has permission to assign permissions to that object, even if someone with Administer privileges has revoked explicit permissions for that object. Unlike the administer privileges of the Admins group, this irrevocability is enforced by the Microsoft Jet Database Engine, not the Microsoft Access user interface. Therefore it cannot be revoked through DAO code; it can only be transferred to another user.
There are two ways to transfer ownership of a object. The first is to change the owner using the Change Owner tab in the User And Group Permissions dialog box. The second is to recreate the object. This is usually accomplished by importing it or exporting it into a new database. If you want to secure an entire database, this is the easiest way to transfer the ownership of all the objects. The simplest way to transfer ownership of an entire database and all the objects within it is with the User-Level Security Wizard. You can also transfer ownership of one or more objects by importing, exporting, or copying and pasting. To re-create an object, the person doing the importing, exporting or copying and pasting must have permissions to read the object and its data, if the object is a table or query.

Caution   As already mentioned, the Admin user has the same SID in all workgroup information files. It is therefore critical to security that the Admin user not own any objects. If it does, anyone who has Microsoft Access who can open the database can give themselves permissions to those objects. To see who owns an object, open the Change Owner tab in the User And Group Permissions dialog box.

The RunPermissions Query Property
Microsoft Access queries have a property called RunPermissions, available through the query property sheet. This property determines whether Microsoft Access uses the query user’s permissions or the owner’s permissions when checking the security permissions for each of the source tables in a query. This property is really a user interface construct that maps to the “WITH OWNERACCESS OPTION” clause of the SQL property of the query. This very powerful feature allows you to build secure views of your data that can provide row- and column-level security for your users.
For example, suppose you have a secure database with an Employees table and a separate Salary table. Using the RunPermissions property, you can build views of the two tables that allow one group to view, but not update the salary column, another to be able to view and update the salary column, and a third to only view the salary column if salary is less than a certain amount.
Only the owner of a query can save it if the RunPermissions property is set to Owner’s. Even members of the Admins group of the workgroup information file in use when the database was created cannot save a query created by another user if the RunPermissions property is set to Owner’s. Anyone with Modify Definition permissions on the query can set the RunPermissions property to User’s and successfully save the query.
Either a user or a group can own an object. Because only the owner of a query with the RunPermissions property set to Owner’s can save changes to that query, groups can be set as the owners to aid in group development environments. Create a Developers group, use the Change Owner dialog box to change the owner of the queries to this group, and then add all your programmers to the Developers group. Then any member of the Developers group can edit the query and save changes.
Using RunPermissions Queries to Prevent Users From Viewing Table Designs
For Microsoft Access to display a table or query, it needs to know field names and other field properties such as Format and Input Mask. So for a user to read and display the data in a table or query, that user must also have permissions to read the design of the table or query. That’s why selecting the Read Data Permission check box in the User And Group Permissions dialog box automatically selects the Read Design check box as well. If you don’t want your users to see your table or query definitions, you can use the RunPermissions property of queries to restrict their access to this information.
To prevent users from viewing the design of the tables or queries on which a form is based
 1.	Remove all permissions to the sensitive source tables or queries for the users or groups that you want to restrict.
 2.	Build a new query that includes all the fields you want to include from your sensitive tables or queries. By omitting a field, you exclude access to that field. Similarly, you can define criteria for your query to limit access to a certain range of values.
 3.	Make sure you or a secure group owns the new query.
 4.	Set the RunPermissions property of the new query to Owner’s.
 5.	Grant appropriate data permissions for the new query to the users and groups who you want to be able to update data but not view the table’s design. This usually means Read Design, Read Data, Update Data, Delete Data, and Insert Data.
 6.	Base your forms and reports on the new query. 
  
Your users can update data in the source tables or queries through forms based on the new query. However, they won’t be able to view the design of those tables or queries. If they try to view the design of the new query, they will receive a message that they don’t have permissions to view the source tables or queries. 
Encryption
Encryption is separate from Microsoft Access security. It is used to prevent someone using a file or disk editor from reading or writing data directly to an .mdb file, and bypassing the Microsoft Jet Database Engine. 
Everything in a Microsoft Access .mdb file is encrypted. Microsoft Access uses the RC4 algorithm from RSA Data Security Inc. for database encryption. Microsoft Jet reads and writes all data one page at a time. Pages are 2K in size. At the level that encryption is being done, there is no notion of what is on the page, only that there’s 2K of data that needs to be encrypted and written, or read and decrypted. 
If a database isn’t encrypted, it would be possible for a very knowledgeable person to use a disk editor to read the SID of the database owner or the SID of the Admins group in use when the .mdb was created. Given that SID, they could assume ownership of the database. If you encrypt your database, you prevent this from happening. The User-Level Security Wizard encrypts databases as part of the process of securing them.
Only the owner, or creator, of a database, or a member of the Admins group of the workgroup information file in use when the database was created, can encrypt or decrypt it. To encrypt a database, either use the User-Level Security Wizard or start Microsoft Access without opening a database and then use the Encrypt/Decrypt Database command on the Security submenu of the Tools menu.
Due to the overhead of encrypting and decryption, an encrypted database will run approximately 10-15 percent slower than a database that is not encrypted. Also, encrypted files cannot be compressed by stand-alone programs such as PKZip or by disk compression programs such as Microsoft DriveSpace.
Using the User-Level Security Wizard and Common Security Scenarios
The Microsoft Access User-Level Security Wizard provides the easiest way to secure databases. In previous versions, the Security Wizard was only available as an Add-in. In Microsoft Access 7.0, the User-Level Security Wizard has been re-written and is available using the User-Level Security Wizard command on the Security submenu of the Tools menu. The Security Wizard allows you to choose which database object types to secure — tables, queries, forms, reports, macros or modules. The selected object types are secured by revoking all permissions from all user and group accounts except that of the user running the wizard. 
  
Note   The User-Level Security Wizard will only secure databases created by Microsoft Access 7.0. Microsoft Access 1.x or 2.0 databases must be converted using the Convert Database command on the Tools menu before they can be secured using the User-Level Security Wizard.
  
The following sections describe common security scenarios and how to address them.
Scenario 1: Securing an Existing Database with the User-Level Security Wizard
You need to secure a database that was created while the developer was logged on as the default Admin user. A unique workgroup information file was not created in advance, and thus any user accounts that were created will be vulnerable. The following procedure assumes that the Logon dialog box has not be activated and that you are logged on as the default Admin user.
To secure an existing database
 1.	If you haven’t done so before, create a secure workgroup information file using the Workgroup Administrator. Write down the Name, Organization, and Workgroup ID strings that you enter and store them in a safe place. You will need these strings if you ever need to re-create your workgroup information file. 
 2.	On the Tools menu, point to Security and click User And Group Accounts. 
 3.	Create a new user account to be the owner and adminstrator of the database, and then add that user to the Admins group
 4.	Click the Change Logon Password tab for the Admin user and define a password for the Admin user. This will cause the Logon dialog box to appear the next time you start Microsoft Access. 
 5.	Quit Microsoft Access and restart it, logging on as the new user created in step 3.
 6.	Use the User And Group Accounts command to remove the Admin user from the Admins group.
 7.	Open the database you want to secure.
 8.	On the Tools menu, point to Security and click User-Level Security Wizard.
 9.	Select the check boxes for the object types you want to secure and then click OK. 
	The Security Wizard creates a new encrypted database, exports all the objects from the current database, and secures the selected object types by revoking permissions for all users other than the user created in step 3. The original database isn’t changed in any way. The wizard re-creates any links to tables and table relationships in the new database as well.
10.	Create your own users and groups using the User And Group Accounts command on the Security submenu. Assign appropriate permissions to the group accounts, and then add individual users the appropriate groups using the User And Group Permissions command on the Security submenu. Typical permissions might include Read Data and Update Data permissions for tables and queries, Insert Data or Delete Data permissions if you want users to be able to add or delete records, and Run/Open permission for forms and reports.
  
The new database is now secure. The only people who can use the objects in the new database are those to whom you gave permissions in step 10 and anyone who is a member of the Admins group of the workgroup information file in use when you ran the User-Level Security Wizard.
Scenario 2: Removing Security from a Secured Database
You need to make a secured database open to all users of Microsoft Access. The SIDs of the Admin user and the Users group are the same in all workgroup information files. By giving permissions for an object to the Users group and the Admin user, you unsecure that object for all users. 
Removing security from a secured database
 1.	Make a backup of the database.
 2.	Start Microsoft Access, log on as someone who has Administer permissions for all the objects in the database, and then open the database.
 3.	Use the User And Group Permissions command on the Security submenu to give the Users group full permissions for all objects in the database.
 4.	Use the User And Group Permissions command on the Security submenu to give the Admin user full permissions for all objects in the database.
 5.	Quit Microsoft Access and restart it, logging on as the Admin user, and then use the User And Group Accounts command on the Security submenu to change the password for the Admin user to null (blank). This will turn off the Logon dialog box.
  
Your database is now completely unsecured. Anyone who can open the database has full permissions for all the objects in it.
Scenario 3: Securing an Application with a Split Application Database and Data Database
You need to secure a database that uses a split frontend/backend architecture. Your data is in stored in Data.mdb, and your code, forms, reports, and other objects are in Application.mdb, along with linked tables pointing to tables in Data.mdb. You want to secure both databases and distribute them to your users. When they install Application.mdb, you want them to be able to re-link to the tables in Data.mdb, based on network share name that will be kept in Data.mdb, and you don’t necessarily know the name of this share when you are securing the databases. For more information about split databases, see “Splitting Databases” later in this section.
To secure an application with a split architecture
 1.	Follow the steps to secure a database using the User-Level Security Wizard for both databases.
 2.	Grant your users the permissions you want them to have for the tables in Data.mdb (Read Data, Update Data, Insert Data or Delete Data). You can either grant users permissions directly for the tables in Data.mdb or you can leave those tables completely secured, and perform all access using RunPermissions queries stored in Application.mdb.
 3.	Make sure your users have Run/Open permissions on Data.mdb. This is required even if you are using RunPermissions queries. 
 4.	In Application.mdb, grant your users Modify Design permissions for the linked tables.
 5.	When the users first install the Application.mdb file, have them run the Linked Table Manager command on the Add-ins submenu of the Tools menu to refresh the links to the tables in the new location of Data.mdb.
  
For more information about RunPermissions queries, see “Using RunPermissions Queries to Prevent Users From Viewing Table Designs” earlier in this chapter.
Because the users have Modify Design permissions for the linked tables, they can reset the connect string to them if the file system location of Data.mdb ever changes. However, they won’t be able to make any modifications to the design of the real tables in Data.mdb.
Scenario 4: Securing Your Database Without Requiring Users To Log On
If you want to secure some objects, such as your modules, in a database, but you don’t care about granting different permissions to different classes of users, you can secure your application without making your users log on.
To secure your database without requiring users to log on
 1.	Follow the steps to secure a database using the User-Level Security Wizard. 
 2.	While logged on as a member of the Admins group, assign the permissions that you want to be available to all users to the Admin user. 
 3.	Confirm that the Admin user is not a member of the Admins group. This prevents users who are logged in as Admin from granting themselves further permissions. 
 4.	Clear the password from the Admin user. 
  
Users will be able to open your database without logging on and will be able to perform all actions you granted to the Admin user in step 2. 
Now you need a way to perform administrative duties such as setting permissions and assigning users to groups. Because you have removed the Admin user from the Admins group, you won’t be able to perform these actions when logged on as Admin. And because the Admin user has no password, the Logon dialog box won’t be displayed. You’ll need to log on as a member of the Admins group to perform these duties.
To perform administrative duties, you can either reactivate the logon procedure and log on as a member of the Admins group, or you can define a shortcut and use the /Pwd and /User command-line options to specify your password and user name when starting Microsoft Access. If you choose to keep this shortcut on your computer, rather than deleting it and recreating the command line each time, you’ll have to make sure your computer is physically secure, because someone could copy the user name and password strings arguments from the shortcuts command line and gain access to your system.
Scenario 5: Configuring a Remote Workgroup so that On-Site Administrators can Manage User Accounts Without Gaining Permissions to Objects
You have a multiuser application developed in Microsoft Access that will be administered by users at a remote site. You want to lock up code and other objects to protect intellectual property, and to prevent users from inadvertently breaking the application. Different users at the sites have permissions to different forms in the database because they are authorized to perform different duties. You don’t want to manage individual user accounts yourself because you are not on-site and they change frequently. You want to grant remote administrators the ability to manage user accounts without giving them access to code and the design of objects.
To give permissions to manage accounts but not to access code and the design of objects
 1.	Using the Workgroup Administrator, create a secure workgroup information file. This will be the master workgroup file for your database.
 2.	Log on with this workgroup and follow the steps to secure the database using the User-Level Security wizard. 
 3.	Create your own custom groups that correspond to the different levels of permissions that you want your remote users to have. Write down the exact names of these groups (case sensitive) and the Personal ID you use to create them. You will need these strings later.
 4.	Assign the appropriate permissions to these groups. Don’t grant Administer permissions to anything; just grant the permissions that are necessary for users to run the application and perform their appropriate functions. At minimum, this would probably be Run/Open for the database, forms, reports, and macros; and Read Data and Update Data for tables and queries. You may also want to grant Insert Data and Delete Data permissions for tables and queries to allow users to add and delete records. 
 5.	Use the Workgroup Administrator to create a new workgroup information file that you will distribute with the application. Make sure you use different strings for the Name, Company Name, and Workgroup ID, than the corresponding strings you used for the master workgroup file.
 6.	Log on under the workgroup file created in step 5 and recreate the same groups created in step 3, using the identical case-sensitive names and the same Personal IDs. 
 7.	Create a user account for your remote administrator to use, and add it to the Admins group of the workgroup file you created in step 5. 
 8.	Remove the Admin user from the Admins group, and put a password on the Admin user. This will cause the Logon dialog box to be displayed, and will make the administrator account created in step 7 the effective administrator of the new workgroup file. 
 9.	Distribute the workgroup file created in step 5 with your database application. Make sure that users use the Workgroup Administrator to join this workgroup information file.
  
The administrator account created in step 7 will be able to create new user accounts, reset passwords, and add users to the groups that you have already created. As users are added to these groups, they will automatically gain the permissions that you assigned to these group accounts in step 4. This is because the SIDs of the group accounts are identical in both workgroup information files. However, the SIDs of the Admins group in the two workgroups are different. These SIDs are generated from the strings fed into the Workgroup Administrator, and you used different strings in step 5.Because the database was originally secured under the master workgroup information file, not the file created in step 5, the Admins group in the master file has ultimate permission setting privileges over all the objects in the database. So while the administrator account you created in step 7 can add and delete users from the groups you created, that account does not have any special privileges to the other objects, and therefore cannot see or modify the design of any of the objects to which you haven’t granted permissions.
Converting Previous Version Secure Databases to Version 7.0
The conversion process preserves all previously defined security. The same issues apply as for converting databases without security. For more information, see “Converting Databases” in the Microsoft Access section of Chapter 10. There are additional issues regarding converting previous version workgroup information files (called workgroups or system databases in previous versions). For more information, see “Converting Previous Version Workgroup Information Files” in the Microsoft Access section of Chapter 10.
Other Security Enhancements
In addition to database password protection and the integration of the Security Wizard, Microsoft Access for Windows 95 includes the following enhancements.
AllowBypassKey Method
The AllowBypassKey method allows a developer to disable the user’s ability to hold down the SHIFT key when starting an application. When this property is set to True (the default), if the user holds down SHIFT when starting an application, settings made with the Startup command on the Tools menu are ignored and the AutoExec macro does not run. This allows users to display the database window and make whatever changes that they have permissions to make. Users who have the Administer permission for a database can change the AllowBypassKey property for their account. The only way to be sure that a user cannot hold the SHIFT key to start your application and bypass the Startup command settings and the AutoExec macro is to set the AllowBypassKey property to False and remove the Administer permission for the database for that account. Whoever is the owner of the database will be able to change these settings even if that user has not been granted the Administer permission for the database.
Hiding Objects in the Database Container
Hidden is a new property for all objects that allows you to hide database objects in the database window. This property is available on the property sheets of all database objects. A new user preference, Show Hidden Objects, is found on the View tab in the Options dialog box and allows you to display hidden objects. When hidden objects are shown in the database window, they appear with a dimmed icon.
Changing a Workgroup Information File from the Command-Line
Microsoft Access 7.0 provides a new command-line option, /wrkgrp, that allows you to change to a different workgroup information file when starting Microsoft Access. You can use this parameter when using the Run command on the Start menu, or in the Target text box of a shortcut. Use this command-line option in this format:
  
Msaccess.exe <databasename> /wrkgrp <workgroup>
  
where databasename is the full pathname of the database you want to open (optional) and workgroup is the full pathname of the workgroup information file you want to use.
Multiuser Settings
Several options and settings in Microsoft Access affect how a Microsoft Access database application functions in a multiuser environment. These settings, are described in the following sections.
Database Open Modes
There are three ways to affect how a database is opened in Microsoft Access:
·	When you start Microsoft Access you can include a database name on the command line and either the /Excl or /Ro parameter to open that database in exclusive or read-only mode, respectively.
·	You can select or clear the Exclusive check box when using the Open Database dialog box. To open read-only, select the database in the Open Database dialog box, click the Commands And Settings button, and then click Open Read Only.
·	You can change the default database open mode using the Options command on the Tools menu, changing the Default Open Mode For Databases setting under the Advanced tab. The setting can be Exclusive for single-user access or Shared for multiuser access to the database.

Tip   In Microsoft Access 1.x and 2.0, using the Options command on the View menu and setting the Default Open Mode set only the default behavior, which the user can still override. The same holds true for Microsoft Access 7.0, where this setting is available using the Options command on the Tools menu. Because the introduction of Microsoft Access 2.0, you can prevent a user or group from opening a database in exclusive mode by removing the OpenExclusive permission of the database for that user or group. This only works if user-level security has been defined for the workgroup.
  
The Refresh Interval
Using the Options command on the Tools menu, you can also set the refresh interval. Microsoft Access automatically checks the recordsets of open forms and datasheets to see whether changes have occurred at the frequency set by the refresh interval. The default refresh interval is 60 seconds, which may be too long for some applications. If you set the refresh interval to too small a value, however, you may create excessive network traffic. Finding the proper setting for your application may require some experimentation. In general, the smaller the network, the smaller you can set the refresh interval without adverse effect.
You can override the default refresh interval in your applications by using the Refresh method, the Requery method, or the Requery action. Record refreshes—either automatic refreshes by Microsoft Access using the refresh interval or manual refreshes using the Refresh method—are faster than Requeries. New records added by other users, however, appear only after a Requery (method or action), and records deleted by other users vanish from your copy only after a Requery. However, all the values in the fields of deleted records are replaced with the string “#DELETED” when the record is refreshed.
In most cases, you should use the Requery method rather than the almost-equivalent Requery action. The method reruns the query that’s already in memory, while the action reloads it from disk. The exception to this rule is when you have used DAO to modify the underlying query definition. You should then use the Requery action to reload the QueryDef from disk.
  
Tip   Even if you leave the refresh interval very high, Microsoft Access automatically refreshes the current record whenever a user attempts to edit it. The benefit of a shorter refresh interval lies chiefly in giving quicker visual feedback when someone else has locked or changed a record while you are viewing it.
  
Locking Options
To provide concurrent access to records by multiple users, Microsoft Access locks records. But unlike some other databases, Microsoft Access doesn’t lock individual records; instead it locks a 2K (2048 bytes) page of records. The advantage of page locking is that there’s less overhead and generally better performance over true record locking when performing operations that affect many records. Unfortunately, this also means that Microsoft Access usually locks more records than you would like. This is especially an issue when you employ pessimistic locking (which is defined later in this section) because this type of record locking allows users to keep records locked for long periods of time.
In a multiuser environment you can open recordsets in one of three different modes:
·	No Locks   This is often called optimistic locking and is the default setting. With the No Locks setting, the page of records that contains the currently edited record is locked only during the instant when the record is being saved—not during the editing process. This allows for concurrent editing of records with fewer locking conflicts.
	For forms and datasheets, two or more users can edit the same record simultaneously. If two users attempt to save changes to the same record, Microsoft Access displays a message to the user who tries to save the record second. This user can then discard his or her record, copy his or her record to the Clipboard, or replace the record changed by the other user.
	For reports, no records are locked while the report is previewed or printed. Except if a report is printing data from Memo or OLE Object fields, in which case that record will be locked until Microsoft Access is finished reading the Memo or OLE Object field’s data.
	For queries, no records are locked while the query is run. Except for action queries, where all records will be locked until the action query is finished.
·	Edited Record    As soon as a user begins to edit a record, the page containing the currently edited record is locked until the changes are saved. This is known as pessimistic locking.
·	All Records    This setting causes all the records in the entire recordset to be locked at once. You won’t find this option very useful except when doing batch updates or performing administrative maintenance on tables.
	For forms, all records in the underlying table or query are locked while the form is open in Form view or Datasheet view.
	For table and select query datasheets, all records are locked until the datasheet is closed.
	For reports, all records are locked while the report is previewed or printed.
	For action queries, all records are locked while the query is run.
	Although users can read the records, no one can add, delete, or edit any records until the form or datasheet is closed, the report has finished printing, or the query has finished running.
  
You can set the default record locking behavior for most objects that access recordsets on the Advanced tab in the Options dialog box. These defaults affect the following objects:
·	Table datasheets
·	Select query datasheets
·	Crosstab query datasheets
·	Union query datasheets
·	Update queries
·	Delete queries
·	Make-table queries
·	Append queries
·	Forms
·	Reports
  
If the default is set to No Locks, it will be ignored for Update, Delete, Make-table, and Append queries, because records must be locked (either Edited or All Records settings) during these operations. Additionally, all records must be locked when using a Data-definition queries.
You can set record locking behavior for individual forms, queries, or reports by opening the object in Design view and setting the RecordLocks property. This allows you to override the default setting made using the Options command on the Tools menu.
Whether you set locking behavior using the Options command on the Tools menu or by setting the RecordLocks property, when the data comes from an Open Database Connectivity (ODBC) database, the Microsoft Access setting is ignored (equivalent to No Locks). All locking for linked ODBC tables, such as Microsoft SQL tables, is determined by the ODBC server application.
Choosing a Locking Strategy
The following list of advantages and disadvantages will help you decide which locking strategy is best for your particular application.
The advantages of pessimistic locking (Edited Record setting) are:
·	It is simple for the developer.
·	It prevents users from overwriting each other’s work.
·	It may be less confusing to the user than optimistic locking.
·	It works well for small workgroups or where users are not likely to be editing the same record.
  
The disadvantages of pessimistic locking are:
·	It will usually lock multiple records; how many depends on the size of the records.
·	When a user is at the end of a table and thus has locked the last page, other users may be prevented from adding new records.
·	It is not recommended where lots of users will be editing the same records or where lots of users will be adding new records at the same time.
  
The advantages of using optimistic locking (No Locks setting) are:
·	It is simple to use.
·	It allows more than one user to edit the same record at the same time. (In some cases, this may be a disadvantage.)
·	It is less likely to lock other users out of records.
  
The disadvantages of using optimistic locking are:
·	It may be confusing to the user when there’s a write conflict.
·	Users can overwrite each other’s edits.
  
Unless you have a compelling reason to use pessimistic locking, you should consider optimistic locking. In most applications, you don’t want your users prevented from being able to edit or—even worse—add new records for potentially long periods of time. If you decide to use pessimistic locking in your forms, you will have to teach your users to recognize and deal with locked records.

Under pessimistic locking, users are locked out of being able to change a record that is on the same page as a record being edited by another user. (Note the slashed-O icon in the record selector.)
On the other hand , you employ optimistic locking in your forms, you will have to teach users how to deal with the Write Conflict dialog box.

Under optimistic locking, users may encounter the Write Conflict dialog box when attempting to save a record that has been changed by another user.
  
Tip   If you have set the RecordSelector property of a form to No, the slashed-O icon does not appear when a record is pessimistically locked. Microsoft Access beeps at the user, but other than this audible signal, users won’t have any clue as to why they cannot edit the values in the record. No trappable error is generated, either. Thus, it’s important to leave the RecordSelector property set to Yes when using pessimistic locking with bound forms.
  
In some applications you may need to use both strategies on different forms. For example, in an inventory application you must ensure that the QuantityOnHand column is pessimistically locked so that salespeople don’t try to post a sale beyond QuantityOnHand without invoking back-order processing. On the other hand, you might use optimistic locking on a vendor address form, as it’s unlikely that two change-of-address requests for the same vendor will be given to two different users for posting at the same time.
Forcing Access to Lock Individual Records
You can force Microsoft Access to lock individual records by creating record sizes that are larger than half a page—that is, larger than 1024 bytes. This works because Microsoft Access won’t begin storing a new record on a partially filled page if it cannot fit the entire record on that page. This strategy wastes a lot of disk space and increases network traffic. However, if you decide to use pessimistic locking and absolutely must have record locking, you may want to consider this technique.
Estimating Record Size
You can estimate the size of your records by using the following table and summing the size of each column:
  
Column datatype	Storage size

Byte	1 byte
Integer	2 bytes
Long Integer	4 bytes
Single	4 bytes
Double	8 bytes
Currency	8 bytes
AutoNumber (depends on FieldSize)	Long Integer = 4 bytes; Replication ID = 16 bytes
Yes/no	1 bit
Date/time	8 bytes
Text	variable
Memo	14 bytes
OLE	14 bytes
The contents of memo and OLE-type columns are stored elsewhere in the .mdb file, so you only need to count the overhead for their address pointers. Text columns present the greatest problem for estimating record size because they’re variable-length fields. Microsoft Access uses 1 byte per actual stored character. Zero-length strings use 1 byte; null strings use 0 bytes.
You also have to account for overhead, which includes the following:
·	Seven bytes per record for record overhead.
·	One byte variable-length column overhead for each text, memo, and OLE column.
·	One additional byte for every 256 bytes of the total space occupied by all text, memo, and OLE datatype columns.
·	One byte fixed-column overhead for each yes/no, byte, integer, long integer, counter, single, double, and date/time column.

Note   The above numbers can only be used to estimate the record size.
  
The easiest way to pad a record to exceed 1024 bytes is to create one or more dummy text columns in the table with default values that are 255 characters long. For example, if you estimated your record size to be at least 130 bytes (considering the minimal size of any text fields), you would calculate the needed dummy fields as follows:
·	Bytes you will need to pad = (1025 - 130) = 895 bytes.
·	Each whole dummy text field would occupy (255 + 2 bytes overhead) = 257 bytes.
·	So you would need three completely-filled dummy fields (257*3=771) of 255 x’s plus one partially-filled dummy field of (895 - 771 - 1 overhead byte) = 123 x’s.
  
Don’t place these dummy columns on your forms. Whenever a new record is created, Microsoft Access will automatically create a record with the four x-filled dummy fields, which forces it into record-locking mode.
Splitting Databases
No matter which locking scheme you use, you are still left with the fact that Microsoft Access puts everything (that is, data, forms, reports, queries, macros, and code) in a single database by default. Performance can suffer considerably because every time an object, such as a form, is used, it must be sent across the network to the user. In a production setting, where nothing but the data stored in tables is being changed, much of this network traffic is unnecessary.
You can eliminate this unnecessary traffic by splitting the database into an application database (sometimes referred to as a front-end database) and a data database (sometimes referred to as a back-end database). Install the data database, with tables only, on the file server and a copy of the application database, containing all other objects, on each workstation. From each copy of the application database, use the Link Tables command on the Get External Data submenu of the File menu to link the set of tables in the data database.
If your database is in Microsoft Access 7.0 format, you can use the Database Splitter command on the Add-ins submenu of the Tools menu to split your database and link tables in a single operation.
  
Tip   If your network supports Universal Naming Convention (UNC) format, use the UNC pathname to specify the path to linked tables using this format:\\server\share\path\Filename.ext. If you specify the path to a linked table using a mapped drive letter, the link to the table will break if another user opens that copy of the application database and the network drive is not mapped or is mapped to a different letter on that user’s computer.
  
There are several advantages and disadvantages to splitting your databases.
The advantages are:
·	Performance, especially user-interface performance, is improved considerably.
·	You can create temporary tables on each workstation and not worry about naming and locking conflicts for temporary objects.
·	Splitting the database makes the updating of applications easier because the data and application are kept separate. Changes to the application can be made off site and easily merged back into the application database without disturbing the data.
  
The disadvantages are:
·	Microsoft Access ignores referential integrity between local and remote tables. Fortunately, Microsoft Access enforces any referential integrity constraints you’ve established between individual tables in the remote database.
·	Microsoft Access hard-codes the paths to linked tables. This means that if you move the data database, you have to delete and re-link all linked tables.
  
Managing Linked Tables
Because Microsoft Access hard codes linked table paths, their use requires extra maintenance for you. If you move the data database with linked tables, you have to delete and re-link those tables. Use the Linked Table Manager command on the Add-ins submenu of the Tools menu to automate the process. 
Other Multiuser Issues
This section covers additional issues you might encounter when using a multiuser database with Microsoft Access.
Correctly Backing Up Multiuser Databases
To back up a multiuser database correctly, make sure that you have exclusive access to the database. If you back up a database while others are using it, you risk producing a damaged backup database. If you open such a backup database, you might receive an error message that the database is corrupted. If you repair and compact the database, the data in the database might be truncated.
The only way to ensure the integrity of your backup database is to open a static copy of the database. To do so, you must have exclusive access to all the tables in the database at the same time. After you have exclusive access to the database, you can copy or export the database, and then archive it.
Microsoft Access Locking and Novell NetWare
When using data from a server back end, Microsoft Access uses the locking facilities provided by that back end. The defaults in NetWare 3.x and 4.x allow a single workstation to have 500 locks at any given time. This results in a limit of 1 MB of data that Microsoft Access can deal with in a single transaction. Because Microsoft Access tries to lock every record involved in either an update or a delete query before actually carrying out the update or delete, it is quite possible to encounter this limit on a moderately large database.
When using Microsoft Access with a NetWare 3.x or 4.x server back end, it is recommended that you increase the number of locks available to avoid encountering the lock limit. To increase the number of locks available, enter the following commands at the file server console or in your Autoexec.ncf file:
  
set maximum record locks per connection = 10000
set maximum record locks = 200000
  
The first parameter is the most locks any single connection can have, and the second is the most the entire server can keep track of. These values (10,000 and 200,000, respectively) are the maximums that NetWare can accommodate. Microsoft Access can handle a transaction of up to 20 MB of data when you set the maximum record locks per connection to 10,000. 
There is an error in the NetWare 3.11 that can result in a server abending (abnormally ending) if the lock limit is exceeded when Microsoft Access is running certain queries or otherwise requesting a large number of locks. If you are still using NetWare 3.11, it is highly recommended that you download the latest NetWare 3.11 patch file which is available on CompuServe in the NOVFILES download area. You will need to load two of the Netware Loadable Modules (NLM) from this file, either directly from the server console or by adding the following commands to your Autoexec.ncf file:
  
load patchman.nlm
load ttsfix.nlm 
  
This problem is specific to NetWare version 3.11 and has been fixed in later versions of NetWare.
Workgroup Features for Microsoft Excel
The new Shared List feature allows multiple users to open a workbook and make changes to it at the same time. Uses of Shared Lists include inventory control tracking lists and consolidation of data from multiple users into the same workbook.
A workbook that has been made a Shared List can be saved to a network or shared drive location; users use the Open command on the File menu to open the file, and then enter or edit data, and save and close the file as they would any other file. The word “Shared” is appended to the filename in the Title bar, similar to the way in which “Read-Only” is appended to a filename that is opened as a read-only file.
If two or more users edit a Shared List during the same session, changes made to the same workbook cell are presented to the users for resolution. This conflict resolution occurs when the file is saved by the users. The first user to save the file sees no conflict — the save occurs normally. The second user to save the file sees the Conflict Resolution dialog box. This dialog box displays the sheet name, cell location, and editing change made by the user, as well as the date, time, content of the conflicting data, and name of the user who entered the conflicting data. The second user saving the file must resolve all conflicts before the file can be saved.
A log of the resolved conflicts is maintained in a Conflict History sheet and placed as the final sheet of a Shared List. This sheet is only visible to the user if the user has selected the Show Conflict History check box on the Editing tab in the Shared Lists dialog box. While entries made to the Conflict History sheet are locked, this log can be autofiltered. If a Shared List file is later saved as an exclusive workbook under another filename, or any user makes the file exclusive by clearing the Allow Multi-User Editing check box on the Editing tab in the Shared Lists dialog box, the Conflict History sheet is discarded from the exclusive workbook..
Using Shared Lists on a Network
File locking on a Shared List file can occur when one user is completing the actions required in the Conflict Resolution dialog box and another user attempts to open or save the Shared List at the same time. Microsoft Excel displays a message telling the user who is attempting to open or save the Shared List file, that the file is being used and that the user should try again later.
File locking can also occur if one user saves a Shared List back to an exclusive state while other users have the workbook open. When the remaining users attempt to save, a message will notify them that the file is an exclusive file and can no longer be saved in shared mode. If users of a Shared List file want to have a copy of the Shared List separate from other users, they should save a copy of the Shared List file to another filename. This will maintain the shared mode of the original workbook and the integrity of the Conflict History log; however, changes made to the user’s exclusive version will not appear in the original Shared List file.
The number of users who can use a Shared List depends on the access limitations set on the network. 
Because of the nature of allowing multiple users to open, edit, and save to the same workbook simultaneously, the following features are disabled when working in a Shared List:
·	Formatting cells
·	Inserting partial rows or partial columns
·	Inserting or deleting worksheets
·	Defining or creating names
·	Creating and modifying dialog boxes
·	Modifying menus
·	Creating and formatting charts
·	Creating PivotTables 
·	Creating or modifying outlines
·	Drawing 
·	Modifying styles
·	Protection
·	Activating OLE objects
·	Saving formula entries 
·	Modifying macro sheets
  
Worksheet functions and formulas can be entered in a Shared List file. However, the user will be notified that the formula can be entered for calculation purposes but not saved.
Existing macros can be run, but macros cannot be recorded or written into a Shared List file. If you run a macro that includes an operation not supported by a Shared List file, the macro will stop, and a message will be displayed.
New Shared List Visual Basic Properties
The Visual Basic for applications interface for Shared List introduces new properties for the workbook object. These can be found in the Microsoft Excel Visual Basic Reference section of Microsoft Excel online help.
Workgroup Features for Microsoft PowerPoint
In PowerPoint, you can import an existing outline to create a new presentation or add an outline to an existing presentation. You can import outlines from Microsoft Word or another word processor. PowerPoint can read outline files in RTF (rich text format) and plain text formats. Users can create presentations from Word documents created by co-workers, as well as export the content of their presentations for use by others in the workgroup. The Presentation Conferencing feature allows a user to give an onscreen presentation for up to 64 other PowerPoint 7.0 users connected to the same local area network.
Exchanging Content Between PowerPoint and Word
Several features in PowerPoint make it easier than ever for your users to reuse existing information without retyping or reformatting.
Report-It
This button on the PowerPoint Standard toolbar exports the text from the current presentation slides to Word as an outline, using Word heading styles. Slide titles become Heading 1 text, and subordinate bullet items become Heading 2, Heading 3, and so on, up to Heading 6. Clicking the Report-It button starts Word and exports the active presentation.
Write-Up
This command on the PowerPoint Tools menu exports an entire presentation to Word. Slide images are created as embedded objects or links in Word, and text from Notes pages associated with each slide is placed adjacent to or below the slide images, at the user’s discretion. Slide images and notes are placed in Word tables, with several optional layouts.
  
Note   Write-Up links only the slide images in the Word document it creates. Notes Pages text content is not linked.
  
Exporting Black & White Slide Images
PowerPoint provides the Black and White View feature, which renders the current slide view in black and white, optimizing colors and patterns for printing on a black-and-white printer, and allows you to adjust for any problems before printing. Slide images you export to Word using the Write-Up feature normally appear in color. If you want to export black and white slide images for optimium black and white printing, click the B&W View button on the PowerPoint Standard toolbar (or the Black and White commmand on the View menu) before choosing the Write-Up command. 
Slides From Outline and Slides From File
The Slides from Outline command on the PowerPoint Insert menu allows you to specify a file created by a word-processing program from which PowerPoint extracts the outline structure and creates a new slide show. The Slides From File command on the Insert menu allows you to specify a file created by PowerPoint or other presentation programs, from which PowerPoint extracts slides.
PowerPoint imports up to 9 heading levels. Heading 1 becomes the Slide title, Headings 2 through 6 become slide bullet item levels 1 though 5. Any heading levels below 6 are imported as level 5 bullet items. Body text and heading levels lower than 9 are ignored.
Meeting Minder
Using the Meeting Minder command on the PowerPoint Tools menu, you can record minutes of a meeting for each slide, read and enter text on notes pages for each slide, and record action items that are placed on a new slide inserted at the end of the presentation.
The Meeting Minder includes an Export button, which sends the text you enter for meeting minutes and action items to Word. When you export from the Meeting Minder to Word, a new Word document is created and headed with the name, time, and date of the presentation, followed by headings for minutes and action items. Minutes are recorded on a per-slide basis and include sub-heads for each slide to which minutes have been added. Action items are listed in one place for the entire presentation.
PowerPoint Presentation Conferencing
PowerPoint 7.0 includes a new command on the Tools menu called Presentation Conference. With this feature, a user on one computer can control multiple instances of PowerPoint 7.0, up to 64 networked computers plus the controlling computer. 

This diagram illustrates a simple, three-computer presentation conferencing scenario. Computer A, located in Oregon, controls the presentation. Computer B in California and Computer C in Ireland are presentation nodes being controlled. Although all the computers must be connected to the same LAN, they need not be in proximity. Computer A sets up the links to computers B and C, and then launches the slide show using the Presentation Conference Wizard. In the wizard, the presenter (computer A) enters the computer names of computers B and C, indicates the control components to display on computer A during the conference (Meeting Minder, Slide Meter, and so on), and initiates the slide show on all three machines. Besides changing slides, the presenter (computer A) can review notes, create action items, monitor the time, and get private previews of other slides. However, computers B and C show only an apparently smooth-running and uninterrupted slide show.
Presentation Conferencing requires the following:
·	Each computer must be connected to the same network. Remote connection via modem is not supported.
·	Each computer must enable file sharing. (Click Settings, click Control Panel, click the File and Print Sharing button on the Configuration tab, and select the checkbox labeled “I want to be able to give others access to my files.”)
·	Each computer must have PowerPoint 7.0 installed.
·	Each computer must be connected to the same LAN.
·	The TCP/IP network protocol must be installed on each computer. Presentation Conferencing uses the Winsock API.
  
The controlling computer can display and use the following controls, which are not visible on any of the other computers:
·	Slide Navigator
·	Slide Miniature
·	Meeting Minder
·	Slide Meter
·	Stage Manager Toolbar
  
Starting a Conference
First, the presenter needs to know the network identification of each computer that will be participating in the conference. You must gather this information from each audience member before you begin. To find a computer’s name, click the Windows 95 Start button, point to Settings and click Control Panel, double-click the Network icon, and click the Identification tab.
  
Tip   You can use the Save List and Open List buttons in the Presentation Conference Wizard to save and reuse lists of audience computer names, called Conference Address Lists. These files are saved in the My Documents folder by default, and are given the .cfl file extension. You can save multiple address lists for different audience groups.
  
Each user who wants to participate in the conference must also choose the Presentation Conference command, select the Audience option, and must click the Finish button in the Presentation Conference Wizard before the presenter does. All audience members must complete this sequence before the presenter can start the conference. After the conference is under way, no new audience members can join the conference.
About the Local Presentation Files
When the connection is made, each presentation node copies the presentation file from the host computer into its Windows\Temp folder, named with the standard temporary-file naming scheme. The presentation opens as an untitled presentation on each of the audience members’ computer, At the end of the conference, the presentation remains open on each computer. If the file is closed, the temporary file is discarded. The audience member can, however, save the presentation instead of discarding it, so make sure not to leave information you don’t want to share in your slides or notes pages.
The Presenter's Control Panel
When running a presentation conference, the presentation control panel is used by the presenter to control many aspects of the presentation using the mouse. 
The controls available on the control panel are:
  
Control Panel section	Control	Description

Slides	Next Slide	Advances to the next non-hidden slide.
	Previous Slide	Goes back to the previous non-hidden slide.
Screen Controls	Pen	Activates the pen for drawing on slides. Drawings appear on audience computers when the presenter releases the mouse button after each drawing.
	Erase Annotations	Erases on-screen drawings on all computers.
	Black Out Screen	Blacks out the screen. Button remains depressed until presenter clicks it again.
Tools	View Meeting Minder	Launches the Meeting Minder.
	View Slide Navigator	Launches the Slide Navigator.
	View Slide Timer	Launches the Slide Timer.
	Send Slide button	Sends the Action Items slide to the audience.
End Show button		Ends the slide show.
Using the Pen for Whiteboard Meetings
Using slides with plain backgrounds (or a blank slide) and the Presentation Conferencing feature, you can conduct a whiteboard meeting, in which each audience member can, in turn, make comments using onscreen drawing. Using the pen, the presenter can draw directly on slides. Each audience member can also use the pen to draw on slides during a presentation. Each pen annotation is broadcast to all other audience members as soon as the mouse button is released.
Playing OLE Objects During Conferences
Objects, such as sound or video clips that play when double-clicked, will play on the presenter’s computer, but not on the audience computers. Similarly, if you double-click embedded static objects such as drawings or graphs to activate the OLE server application for editing, the action is not displayed on audience computers. 
However, sound effects applied to build sequences using the Animation Settings command will play on audience computers, provided the computers are equipped with the necessary hardware and software to play sounds.
Workgroup Features for Microsoft Word
This section describes tools your workgroup can use to more easily share and manage Word documents easier.
Distributing Documents with Word Viewer
Word Viewer is a scaled down version of Word that displays and prints Word documents, but does not allow editing. With Word Viewer, anyone in your workgroup or organization that does not have Word can view and print Word documents. Word Viewer does not require you to take additional steps to get your source documents into a distributable and readable format. Word Viewer users get the same page fidelity, viewing and printing options as regular Word users.
There are two Word Viewer applications for different operating systems. Both are included on the Office Resource Kit CD-ROM. For installation instructions, see Appendix D, “Contents of the Office Resource Kit CD.” The two Word Viewer applications are:
·	Word Viewer for Windows 95 and Windows NT 3.51. This is a full 32-bit application and fully supports Word 7.0 documents.
·	Word 6.0 for Windows Viewer. This is a 16-bit application and runs under Windows 3.1, Windows 95, and Windows NT 3.51. However, it does not have the Word 7.0 look and feel and can only read files that follow the MS-DOS 8.3 file naming convention. Any highlighting done with the Highlighting button in Word 7.0 will not be visible when the document is viewed with the 16-bit Viewer.
  
Word Viewer users can: 
·	Open any document created in Word for Windows, version 2.0 or later, and Word for the Macintosh, version 4.0 or later.
·	View a document in Normal, Outline, Page Layout, or Full Screen view.
·	Print a document with the same fidelity as is provided in Word. 
·	Copy text or graphics out of a document.
·	View annotations previously made to a document.
·	Activate embedded OLE objects in a document. However, the user cannot save changes made in the object after the OLE server has been closed.
  
Word Viewer users cannot:
·	Cut text out of or paste text into a document.
·	Save any changes to a document.
·	Use Word Viewer with the Internet Assistant to browse hyperlinked documents.
·	Update fields, except for the FILLIN field. However, changes made with the FILLIN field cannot be saved because Word Viewer cannot save changes to a Word document.
·	Create, modify, or run macros.
·	Create annotations.
·	Use revision marks.
·	Display pictures in documents created in Word for the Macintosh.
·	Display linked pictures.

Tip   To achieve higher fidelity in your documents when they are viewed on other systems with Word Viewer, use TrueType fonts and embed them in the document. In Word, click Options on the Tools menu. Click the Save tab, and select the Embed TrueType Fonts check box. If possible, also select the same printer driver that your Word Viewer users have access to.
  
Word Viewer is freeware; you can distribute it freely to any number of Windows users. Versions of Word Viewer for MS-DOS, the Macintosh, and other operating systems are not available. 
Create, Share and Explore Documents on the World Wide Web with Internet Assistant
Internet Assistant is a free add-on program that enables users of Word for Windows 95 and Windows NT 3.51 to share information on the World Wide Web, a global network of servers on the Internet. Internet Assistant allows your workgroup to use the familiar interface in Word to create documents for the World Wide Web in Hypertext Markup Language (HTML). Internet Assistant has Web browsing capabilities built in, so users can test hyperlinks as they write as well as retrieve information from the World Wide Web without ever leaving Word.
Another great use of Internet Assistant is to create webs of linked Word documents on a local area network. Even if your workgroup does not have Internet access, individuals can still create and browse through Word documents that include links to other documents, including documents with embedded OLE objects. This makes Internet Assistant and Word a great combination for in-house document libraries. For more information about using Internet Assistant to link documents on a local area network, see “Creating a Document Library in Your Organization” later in this chapter.
Browsing with Internet Assistant
With an Internet connection and Internet Assistant for Word, you can connect to and browse the World Wide Web. Users on a local area network can also use Internet Assistant to browse through or create linked documents on a local area network. You also have access to the most popular Internet services because Internet Assistant comes with built-in support for the key Internet protocols: HTTP, FTP, and Gopher. Internet Assistant does not directly support Internet e-mail, however.
Browsing the World Wide Web requires an existing Internet connection via a server (or proxy), or a dialup SLIP/PPP account. The software and hardware to make this connection is not included with Internet Assistant. You must obtain Internet connectivity from an Internet service provider.
Editing with Internet Assistant
Internet Assistant is designed to make it easy for users to create documents for the World Wide Web even if they have never done so before. Internet Assistant lets users automatically convert Word documents to HTML, the standard format for the World Wide Web. Users who want to apply their own HTML styles to documents they create from scratch can do so simply by applying styles in Word. Internet Assistant also installs a unique toolbar that makes it easy to create hyperlinks in either Word or HTML documents and insert horizontal borders and graphics.
  
Note   Internet Assistant creates HTML documents, while Microsoft SGML Author for Word converts between Word text styles and SGML tags. Internet Assistant is not suitable for full SGML authoring.
  
Internet Assistant gives you the option of creating Internet documents in either Word native format or HTML format. Word native format allows you to fully benefit from the rich formatting capabilities in Word so documents can include multiple columns, text wrapped around graphics, and OLE embedded objects. HTML format does not support these advanced features.
Installing and Distributing Internet Assistant
Internet Assistant is freeware; you can distribute it freely to any number of Windows users.
  
Note   The 16-bit version of Internet Assistant supports only Word 6.0a and 6.0c. The 32-bit version of Internet Assistant, described here, supports Word 7.0.
  
Internet Assistant is available from several sources. Depending on where you obtain Internet Assistant, it may be in the form of a single compressed, self-extracting file, or it may be in the form of a Setup program and several other files. You can obtain Internet Assistant from any of these sources:
·	On the Microsoft Home Page of the World Wide Web. To access the Microsoft Home Page, connect to the Internet and use the following URL:
  
HTTP://WWW.MICROSOFT.COM
  
·	On CompuServe, GEnie, and Microsoft OnLine. You can find Internet Assistant in the Microsoft Software Library.
·	From the Microsoft Download Service (MSDL), which you can reach by calling (206) 936-6735. This service is available 24 hours a day, 7 days a week. The highest download speed available is 14,400 bits per second (bps). For more information about using the MSDL, call (800) 936-4100 and follow the prompts.
  
For more information, see Appendix F, “Resources.”
To install Internet Assistant
 1.	Obtain Internet Assistant from one of the sources noted above.
 2.	If you obtained the self-extracting file, double-click it to extract the contents of the file.
 3.	Run the Internet Assistant Setup program.
  
For detailed instructions on using Internet Assistant, install Internet Assistant and refer to the Help and sample documents that are included.
Creating a Document Library in Your Organization
In addition to using Internet Assistant to browse and author for the World Wide Web, you can use Internet Assistant to create a local library of linked Word documents on a local area network. Users equipped with Internet Assistant and Word can author and browse these documents saved in Word format.
For example, your workgroup could have its own home page in the form of a Word document with hotlinks to other documents. If your workgroup has Internet access, these documents could include links to documents on the World Wide Web as well as documents stored on a local area network. Because the Internet Assistant supports the document format in Word, you can use all of the Word formatting and page layout features and OLE embedded objects.