The majority of production Visual Basic 4.0 database applications you create are likely to be used in a multiuser environment. By definition, a multiuser environment requires that all users of a database application be connected by a network in order
to share one or more common database files. Surveys of database users in mid-1995 indicate that more than 90 percent of all database applications are networked. It's likely that your first multiuser applications will run over NetWare, because today Novell
NetWare 3.1+ and 4.1+ have the lion's share of the installed base of local-area networks (LANs). Industry surveys indicate that Windows NT Server 3.51+ is catching up with NetWare in the "new installations" category due to Windows NT
Server's comparative ease of installation and maintenance. Ultimately, probably by 1997, the Internet (a wide-area network or WAN) and company-wide intranet LANs (modeled on the Internet) will become the most common method of deploying
decision-support front-ends created with future versions of Visual Basic.
Microsoft announced on December 7, 1995, their strategy for Internet connectivity on both the client and server side. Microsoft plans an important role for Visual Basic in World Wide Web browser applications, especially applications that require database connectivity. Use of Visual Basic and VBA in conjunction with Microsoft's Internet incentive is discussed in the "Visual Basic and the World Wide Web" section, at the end of this chapter.
Visual Basic developers whose database applications have been limited to single-user products need a grasp of networking methods and terminology. Access 1.x was designed specifically for creating multiuser database applications, but Visual Basic
3.0 was not "network-ready" when it came to such issues as maintaining the security of Jet 1.x or 2.0 database files. Visual Basic 4.0 solves the Jet database security problem with its Users and Groups collections. Therefore, this chapter
begins with a general discussion of network structures, network operating systems and applications, communication protocols, adapter cards, cabling, and other issues that face developers who need to get database applications up and running on a variety of
networks. If you're a networking pro, you can skip these sections. The remainder of this chapter is devoted to network security issues, primarily for shared (multiuser) Jet 2.5 and 3.0 .mdb files. The next two chapters, "Understanding the Open
Database Connectivity API" and "Creating Front-Ends for Client/Server Databases," deal with networked client/server RDBMSs.
Topology in the computer world is a description of how computers are connected in a network. Users can be connected to the network by a variety of network adapter cards, network operating protocols, and cables. A local-area network (LAN) consists of
computers in a single facility that are connected with some form of cabling. You're not restricted to a copper (wire) or glass (fiber-optic) connection to the network; you also can connect with remote dial-up access through a conventional or cellular
telephone equipped with a modem, a leased telephone line, a low-power wireless (radio-frequency or RF) connection, or even a satellite link. LANs in different locations can be connected into wide-area networks (WANs) by high-speed telephone lines using T1,
T3, frame relay, ISDN, CATV cable modems, or ATM hardware and data communication protocols. The concentrators, routers, bridges, gateways, and protocols that are used to create WANs are discussed later in this chapter.
The sections that follow describe the topology of workgroup and client/server networks, the inner workings of Windows NT 3.51+ Server, and the TCP/IP (Transmission Control Protocol/Internet Protocol), which has become the industry standard for
implementing wide-area PC networks, including Internet and intranet WANs.
The primary classification of networks is by scope. The scope of a network is determined by the number and proximity of the computers connected to the network. The basic network scope classifications—workgroup, departmental, and
enterprise-wide—are described in the three sections that follow.
Workgroup networks connect a limited number of users (usually 25 or less) who share files, printers, and other computer resources. Microsoft's Windows Network and, to a lesser extent, Novell's Personal NetWare (formerly NetWare Lite), and Artisoft's
LANtastic networks are typical workgroup network operating systems (NOSs). Workgroup networks usually are self-administered; that is, the members of the workgroup control permissions (also called authority) to share workgroup resources.
Workgroup computers usually are connected by peer-to-peer networks and use a single network protocol. Any computer in a peer-to-peer network may share its resources, such as files and printers, with other computers in the workgroup. Access is designed
specifically for workgroup computing. Figure 18.1 is a diagram of a five-member workgroup network using Ethernet adapter cards and cabling. One of the workgroup computers shares a fax modem and a printer with other members of the workgroup. A coaxial cable
(10Base2, thin Ethernet or ThinNet) is shown as the Ethernet transport medium in the network diagrams of this chapter for simplicity. Today, 10BaseT is the most common network transport medium; 10BaseT and its faster counterpart, 100BaseT, require a hub to
connect more than two computers. Hubs are discussed in the section titled, "Hubs, Bridges, Routers, and Gateways," which follows shortly.
Figure 18.1. A five-member workgroup network with a shared fax modem and laser printer.
Departmental networks use dedicated server computers that provide resources to client workstations, usually within a single facility. Novell NetWare 3.1+ and 4.1+, Microsoft Windows NT Server 3.51+, IBM's LAN Server for OS/2, and Banyan VINES are
examples of client/server NOSs. Departmental networks often include remote access services (RAS) that enable users, such as field salespersons, to connect to the server with a modem-equipped computer. Servers fall into the following three classes:
A variety of computer types (PCs, Macs, and UNIX workstations, for example), each of which uses a different network protocol (such as Microsoft NetBEUI, NetWare IPX, and UNIX TCP/IP), may be connected as clients in a departmental network. Windows 95
and Windows NT supports simultaneous use of NetBEUI, IPX, and TCP/IP protocols. Departmental networks use gateways to connect to mainframe computers. One or more full-time network administrators (NAs or NWAs) usually are assigned to manage departmental
networks. Independent, self-administered workgroups may exist within the departmental network, although most NWAs discourage ad hoc peer-to-peer networking. Figure 18.2 shows a simple departmental network with a single file and/or application
server. The server is equipped with a single- or multi-line modem to provide remote access service to mobile users and telecommuters.
Figure 18.2. A simple departmental network with a shared printer and a RAS modem.
Enterprise-wide networks connect departmental LANs, often across large distances. Figure 18.3 depicts one of the departmental or headquarters LANs that make up an enterprise-wide network. Most enterprise-wide networks use a variety of
communication methods to link LANs into a WAN; the type of interconnection depends on the distance between the individual LANs. Concentrators, bridges, and routers are hardware devices that transfer packets of data between the LANs.
The LAN in Figure 18.3 uses Ethernet running the TCP/IP protocol and includes a connection to a mainframe computer through a gateway, as well as a bridge to a fiber-optic (FDDI) and a copper token-ring network. Connections to North American LANs in the
WAN are made through a T1 switch that provides access to high-speed telephone lines. T1 lines also are used to create dedicated links to the Internet. Overseas subsidiaries communicate through a satellite link. Because of the complexity of WANs, most firms
that operate enterprise-wide networks have a staff that manages the communications aspects of the WAN.
Figure 18.3. A headquarters LAN that acts as the hub of a wide-area network.
Early in the history of PC-based networks, the most common configuration was the departmental LAN illustrated by Figure 18.2, a single file server running NetWare and sharing its resources with a group of workstations. As the number of users in a LAN
grows, additional servers are added to accommodate more shared files and applications, as well as expanding database files. When users number in the thousands and WANs span continents, the simple client/server model no longer suffices for network
administration. Therefore an additional tier, the domain, was added to the client/server hierarchy. The concept of domains originated with TCP/IP and the Internet; when you access Microsoft's Web site, http://www.microsoft.com, you are connected to the
Microsoft domain, microsoft.com. The microsoft.com domain comprises tens of thousands of computers scattered over the globe, but most of the domain members are in Redmond.
Figure 18.4 shows the relationships between two domains (represented by the two domain controllers), servers, and workstations. The interconnection between the Ethernet backbone of each of the domains, shown as a lightning bolt in Figure 18.4, can be
twisted pair (10BaseT or 100BaseT) wire, coaxial cable (10Base2), a fiber-optic link (FDDI), or a T1, T3, FrameRelay, or ATM data line. Only two workstations per domain are shown in the illustration, but a single domain commonly supports 100 or more
workstations and several servers. Users in one domain can share files that are stored on another domain's servers and run applications on other domains.
Figure 18.4. Two interconnected network domains.
The advantage of assigning servers and workstations to domains is that a workstation user can gain access to any server in the domain with a single login operation. Network administrators don't need to create new user accounts for each server in a
domain, because each user account is validated by the domain controller, not by the individual server(s) in the domain. The domain controller maintains the user account records for each person who is authorized to use a workstation in the domain. Domain
controllers also can act as conventional file, application, and/or database servers.
Windows NT Server carries the single-logon process one step further by authenticating user accounts across trusting domains. If the domain responsible for the user's account data is trusted by the other domains to which the domain with the user account is connected, the user automatically has an account in each of the other domains. A full discussion of trust relationships between domains is beyond the scope of this book. The Concepts and Planning Guide that accompanies Windows NT Server provides a complete explanation of domain topology.
If you have more than one server in an Windows NT Server domain, every 5 minutes or so the domain controller replicates the user-account data on each of the servers in the domain. To minimize replication overhead, only changes to the user-account
records are reflected in the servers' user-account tables. Replicating user-account data provides a backup in case of failure of the domain controller. The domain administrator can promote any server to domain controller status; promoting a server to
domain controller demotes the current domain controller to server status.
The examples in this chapter use Windows 95 as the peer-to-peer NOS, Windows NT 3.51 Server (NTS) as the client/server NOS, and both Windows NT 3.51 Workstation (NTW) and Windows 95 as client workstation environments. NTS is a superset of NTW that
provides a number of additional features that are not included in NTW's built-in peer-to-peer (workgroup) networking capability, which is limited to no more than 10 connections per peer server. One of the additional features offered by NTS is trust
relationships between domains (as briefly discussed in the preceding section). Other added features, such as fixed disk fault tolerance and replication, are discussed later in this chapter. SQL Server for Windows NT version 6.0, used in the examples of the
next two chapters, which are devoted to client/server RDBMSs, runs as a service of NTS.
To understand many of the examples shown in this and the next chapter, you need to know the configuration of the computers and the topology of the network used to create the examples. (Otherwise, you might not know why drives with letters such as G:
and H: appear in the examples.) Each of the computers use Intel EtherExpress 16 Ethernet cards connected by thin Ethernet (10Base2) cabling. Here are the specifications and the configuration of the disk drives of the server and workstation computers:
Figure 18.5. Windows 95's Explorer displaying drive letter allocations of the OAKLEAF1 workstation.
At the time this edition was written, the combination of NTS and SQLS 6.0, which are the primary components of the Microsoft BackOffice 1.5 server suite, had the lowest entry cost of any product combination that implements a full-featured, networked
client/server computing environment. (Depending on the number of users, the cost of a NTS/SQLS installation is likely to be less than 25 percent of the cost of a comparable UNIX-based client/server database system.) NTS is much easier to install,
administer, and maintain than any other currently available client/server NOS for enterprise-wide networks, such as Novell NetWare 4+ and Banyan VINES. SQLS is equally easy to install, and includes server administrative tools and utilities that run under
Windows NT, Windows 95, and Windows for Workgroups 3.11 workstations. The ability to run NTS and SQLS on RISC-based computers using either the MIPS 4000/4400 or DEC's Alpha chipsets provides an alternative to the use of PCs based on Intel 80x86 MPUs.
Windows NT 3.51+ and SQLS 6.0 also offer scalability through SMP. Scalability means that you can add additional microprocessor (MPU) chips to a Windows NT server (or workstation) to achieve improved performance with multithreaded applications that take advantage of SMP. Windows NT 3.5+ Server and Workstation can divide processing chores between as many as 16 processors. Increasing the number of MPUs, however, does not always lead to improved server performance. Many server operations, such as file replication, import, and export are I/O bound. Adding additional memory (beyond 64MB) to increase the size of the disk cache often is more effective in increasing server throughput than adding more MPU chips. Many SMP servers use 128MB or more of RAM to provide improved performance.
When you log on to an NTS network from a Windows NT 3.51 workstation, you specify the domain you want to join in the From text box of the dialog titled Logon to Windows NT. If you're using a Windows 95 workstation, you can join a workgroup and
simultaneously log on to NTS when you launch Windows 95 by following these steps:
When you restart Windows 95, the Welcome to Windows 95 dialog appears with the default domain name—in this example, OAKLEAF0. When you enter your user name and password and then click the OK button, you are logged on to the domain you chose and
become a member of the specified workgroup (Test). After you log on, you can map server shares (shared directories on NTS) to drive letters by choosing Tools | Map Network Drive from Explorer's menu to display the Map Network Drive dialog.
Open the Path drop-down list to choose the server share to map to the specified drive letter (see Figure 18.9); then click OK to close the dialog. Figure 18.10 shows shares of the OAKLEAF0 server's physical C: and D: drives mapped to logical drives I: and
J: of the OAKLEAF1 workstation.
Figure 18.9. Using Explorer to map a shared server folder to a workstation logical drive.
You don't need to map server shares to logical drives on workstations. Windows 95 and Windows NT 3.5+ Workstation support long file names (LFNs) and Universal Naming Convention (UNC) to point to servers (\\ServerName), shares
(\\ServerName\ShareName), and files \\ServerName\ShareName\[Path\]FileName.ext). As an example, \\Oakleaf0\Croot\Ac303\Dsmkt.mdb specifies the Dsmkt.mdb database file in the \Ac303 folder of the C: drive of
OAKLEAF0—the equivalent of I:\Ac303\Dsmkt.mdb for a mapped drive. The advantage to using UNC is that drive letter mappings vary from computer to computer, depending on the complement of physical drives installed and how the drives are partitioned.
Always use UNC to specify shared files in 32-bit applications to avoid the need for application users to map server shares to specific drive letters.
You can share directories of your computer with other members of your workgroup. Creating a workgroup and peer-sharing multiuser database files is useful for limited-scale testing of applications. To share a directory, right-click the folder's icon in
Windows Explorer; then choose Sharing from the pop-up menu to display the Sharing page of the folder's Properties sheet. Click the Shared As option button and enter the alias for the share (up to 12 characters) in the Share Name text box. You can
let anyone access the shared folder by clicking the Read-Only or Full (read-write) option button and leaving the Password text box empty. To restrict access, you can specify a single password for read-write access or two passwords to differentiate users
with read-only from those with read-write access. Figure 18.11 illustrates use of a single password for read-write access. When you click OK to close the folder Properties sheet, the new shared folder appears in Explorer's folder under the folder with the
workgroup name (see Figure 18.12). Folders shared by other workgroup members also appear in the workgroup folder.
Figure 18.11. Sharing a directory in a peer-to-peer Windows 95 workgroup network.
Figure 18.12. Server and workgroup shares shown in Network Neighborhood.
Windows NT 3.51+ Server provides fault-tolerance for the fixed disks of network servers by employing RAID (redundant array of inexpensive disks) methodology. At the time this edition was written, the following five levels (strategies) for providing
fault-tolerance with RAID hardware were available:
RAID level 0 (disk striping only) provides improved fixed-disk read performance by sequentially placing blocks of data on multiple disks. RAID level 0 is not included in the preceding list because RAID level 0 disk striping by itself does not provide fault-tolerance. Raid 0 is primarily of interest in applications, such as non-linear digital video editing, where sustained disk I/O read and write rates of 4 MB/sec and higher are required.
NTS lets you choose either RAID level 1 or RAID level 5 redundancy to keep the network operating despite the failure of a single disk drive. Unless you have a particular reason for choosing RAID level 1, RAID level 5 is currently the favored method of
providing disk drive fault-tolerance. If more than one disk drive at a time fails, you are out of luck because you cannot reconstruct the missing data with either RAID level 1 or level 2 strategies. Low-cost ($300/GB or less) fixed disk drives with an
advertised MTBF (mean time between failures) of 800,000 to 1,000,000 hours were available at the time this book was written, so multiple-drive failure is unlikely unless the server experiences a power surge that your power-line conditioning system cannot
take in stride.
If you believe advertised MTBF figures, the probability of two disk drives failing simultaneously because of mechanical or on-board electronic component malfunction is exceedingly small. On the other hand, the first disk drive installed in the OAKLEAF0 domain controller experienced an unexplained catastrophic failure within the first 96 hours of operation. The replacement drive failed after five days of 24-hour operation. MTTF (mean time to failure) is a more useful measure of the reliability of fixed disk drives, but manufacturers rarely report MTTF values. Fault-tolerance strategies are not a substitute for regular backups of server data.
NTS does not expand greatly upon Windows NT 3.1's tape backup system. Windows NT supports a variety of SCSI and QIC tape drives, including drives that use the 4-mm DAT (digital audio tape) format. Many suppliers of backup tape drives that are not
supported by the drivers included with NTAS provide their own drivers for NT 3.5+.
Hardware products that have been tested and found to perform satisfactorily with Windows NT 3.5+ and the hardware drivers that are included with the retail version of Windows NT 3.51 Server and Workstation are listed in the Hardware Compatibility List that accompanies both versions of Windows NT. Periodic additions to the list of tested hardware products appear in updated versions of the Guide that are available for downloading from Library 1 of the WINNT forum on CompuServe.
Windows NT Server supports a variety of network adapter cards (also called NICs—network interface cards) and operating protocols. Both NTS and NTW use the OSI (Open Systems Interconnection) Reference Model, which divides the flow of data in
a connection between an application running under a computer operating system and the network hardware into the seven layers shown in Figure 18.13. The layered configuration results in the various protocols used to communicate between networked computers
as a stack. Each of the layers in the workstation's stack communicates with the same layer in the server's stack.
The OSI Reference Model has been adopted by the United Nations' International Standards Organization (ISO) and is accepted on a world-wide basis as the standard methodology for network software implementation. The sections that follow provide the
details of Microsoft's implementation of the OSI Reference Model.
Figure 18.13. OSI Reference Model protocol stacks for a workstation and a server.
The protocol stack (also called protocol, transport protocol, or protocol driver) for Windows 3.11, Windows 95, NTW, and NTS includes the transport and network layers. The application, presentation, and session layers are attached to the operating
system kernel (NTW and NTS) or the environment (Windows 95 and Windows 3.11). The data-link layer of each of the three products is based on Microsoft's NDIS (Network Driver Interface Specification) standard for Windows. When you install Windows 95, NTW, or
NTS, you choose the NDIS driver supplied by Microsoft for the adapter card in your computer. The process of connecting the driver to the data-link layer and the adapter card is called binding.
Some network protocols include the transport, network, data link, and physical layer in a single monolithic protocol. The advantage of Microsoft's NDIS approach is that you can use more than one protocol with a single adapter card. In this case, the multiple protocols share the transport and network layers of the protocol stack. The computer first transmits data in the primary protocol and then in the other protocols (if multiple protocols are used). Windows automatically assigns a new number (LANA number) to the adapter card for each protocol in use. Novell's ODI (Open Datalink Interface) is similar in concept to NDIS and also enables multiple protocol stacks, but is not widely used in Windows NT networking systems.
Windows NT 3.51 includes four protocol stacks: NetBEUI, TCP/IP, IPX, and DLC. NTS also includes a protocol stack for the AppleTalk networking system built into all Macintosh computers. The following list briefly describes the purpose and capabilities
of each of the five protocols supplied with NTS:
Although NTS supports the TCP/IP protocol that is primarily used by UNIX applications, there is no provision in NTS for connecting to NFS (Network File System) servers that enable UNIX and DOS/Windows applications to share a common set of files. NFS
was developed by Sun Microsystems, Inc., in 1983 for use with Sun UNIX workstations. Sun offers PC-NFS, an add-in application for Windows 3.11 clients that provides NFS connectivity in Ethernet environments. Several firms offer NFS drivers for Windows NT
3.5+.
TCP/IP is rapidly attaining the status of a de facto protocol standard for wide-area communication between local-area networks. Most firms that have heterogeneous LANs (LANs that support a variety of workstation types or transport protocols) also use
TCP/IP as their primary LAN transport protocol. Virtually all mainframes, minicomputers, RISC workstations, and PC operating systems support TCP/IP, at least over Ethernet cabling. Thus, if you are developing Visual Basic 4.0 database applications for
large organizations, it's likely that you need to deal with TCP/IP.
TCP/IP is a connection-oriented protocol that is made up of two protocols, TCP and IP. The IP protocol establishes a connection between two devices on a network, based on 4-byte (32-bit) addresses; inclusion of the IP address makes TCP/IP a routable
protocol. The IP address is represented by the decimal values of each of the four bytes of the address, separated by periods, as in 115.27.88.33, which corresponds to &H731B5821& in Visual Basic hex notation. The IP address consists of the
following two components:
A second 4-byte value, called the subnet mask, specifies which bytes of the IP address are to be interpreted as the network ID and which are host ID values. You create a subnet mask by creating a 32-bit binary value whose bits are set to 1 in positions
corresponding to the network ID byte(s) and to 0 in positions representing the host ID byte(s). Thus, a subnet mask with a value of 255.255.0.0 (&HFFFF0000&) applied to the IP address used in the preceding example specifies that the network ID is
115.27 and the host ID is 88.33.
An address with a 2-byte network ID and a 2-byte host ID is called a class B network address. A 1-byte network ID and 3-byte host ID is a class A address. A 3-byte network ID and 1-byte host ID is a class C address. Using different address classes enables you to determine how many individual networks can be addressed. As you assign more bytes to network addresses, the number of devices allowed on each network decreases. All computers connected together on a single network must use the same network ID and subnet mask.
Once the connection is created between the two network devices specified by the IP address and subnet mask, TCP creates individual IP packets from the data to be transmitted. Each packet has a header that includes the following information:
Windows NT 3.51 provides the following three basic utility services that are associated with the TCP/IP network protocol:
Microsoft's implementation of TCP/IP does not, in itself, provide file-sharing services between PC clients and UNIX client/server network systems. TCP/IP originally was designed for communication and file transfer, rather than the sharing of files in a multiuser environment. Suppliers of UNIX-based RDBMSs license connectivity products to let DOS/Windows, DOS/WfWg, and NT act as RDBMS clients. You currently need an NFS server (described briefly in the preceding section) and an NFS add-on application to share other types of files, such as desktop database table files, with UNIX workstations.
Windows NT also offers a variety of other TCP/IP command-line utilities, principally for testing network connections (Ping) and interacting with UNIX systems. A complete technical description of TCP/IP, UNIX utilities, and sharing files between
computers running UNIX, DOS/Windows 3.11, and Windows NT 3.51+ is beyond the scope of this book. There are a variety of books now available that are devoted to the subject of UNIX networking. If you are developing a Visual Basic 4.0 database application
that uses a UNIX-based RDBMS such as Sybase System 10 or 11, or needs to share database files with UNIX workstations, an investment in a good UNIX networking book is quickly repaid.
TCP/IP for Windows is implemented with both NBT (NetBIOS over TCP/IP) and the Windows Sockets API (WinSock 2.0). The two implementations share the same levels in the protocol stack. NBT provides naming services so that NetBIOS applications can locate
NetBIOS workstations and servers on the TCP/IP network by a valid NetBIOS name, rather than by a numeric IP network ID. NetBIOS names are the computer names, such as OAKLEAF0, that you assign to PC servers and workstations; NetBIOS names derive from the
original PC peer-to-peer networking application developed by IBM, PC-LAN, and must comply with DOS file-naming conventions. You use the LMHOSTS (LAN Manager hosts) file to associate NetBIOS names with IP addresses. The format of the LMHOSTS file is
identical to that used for the HOSTS file associated with implementations of TCP/IP for DOS, such as FTP Software's PC/TCP, which also includes NFS services. A typical entry in the LMHOSTS file appears as follows:
115.27.88.33 OAKLEAF0
When you specify a computer name or an IP address, the corresponding entry in LMHOSTS provides the required name resolution.
WinSock is modeled after the Berkeley Sockets included in the BSD (Berkeley Software Distribution) version 4.3 of UNIX developed by the University of California at Berkeley. In UNIX terminology, a socket is a bidirectional connector to an
application. Two sockets, each identified by an address, participate in a two-way network conversation. If you intend to create a Visual Basic 4.0 application that needs to connect directly to another application with TCP/IP, using the Windows Sockets API
is the most straightforward approach. Several third-party software publishers, such as NetManage, Inc., provide VBXs and OLE Controls that support WinSock.
PPP (Point to Point Protocol) and SLIP (Serial Link Interface Protocol) are the two most common forms of providing TCP/IP remote access services (RAS). Both PPP and SLIP enable you to redirect TCP/IP transmission from the network adapter card to a
serial port, enabling remote dial-up connection to a network with a server that implements SLIP. NTS supports PPP and SLIP, but Windows 95 supports only PPP. PPP differs from the NetBIOS remote access service (RAS) provided by NTS: PPP lets you run queries
against RDBMS servers using the ODBC API, while NetBIOS-based RAS is designed only for file access operations.
The following four types of hardware devices commonly are employed in LANs and WANs and to connect to mainframe computers:
The security features of Jet .mdb files often are described as labyrinthine or even Byzantine. In reality, Jet's database security system is modeled on conventional network and RDBMS security methodology. Now that Jet 3.0 provides access to the Groups
and Users collections of .mdb files, you can manage individual User and Group accounts with a Visual Basic 4.0 application. You cannot, however, create a secure Jet 3.0 .mdb file with Visual Basic 4.0; only Access 95 can create the required System.mdw
workgroup information file to implement Jet security. If you don't want to use a System.mdw file, you can control access to database files by individual users or groups of users through the security features of the network.
The majority of Visual Basic 4.0 applications can achieve results that are similar or equivalent to the applicable security features built into Access 95 and its predecessors if you implement a well-planned network security system. Even when you use
Access, the first line of defense against unauthorized viewing or modification of database files is network security. The sections that follow describe how network security works in a NTS environment and how to design Visual Basic 4.0 database applications
to take maximum advantage of network security. If you're an Access developer, much of the terminology in the sections devoted to network security will be familiar to you.
Network operations are divided into the following two basic categories:
The basic element of network security in client/server networks is the user account. Administrators and users each must have a user account that enables logon to the network. The user account record, at the minimum, includes fields to hold the user's
logon ID (user name), password, and to indicate the group(s) to which the user belongs. Regular network users must belong to at least one group, most commonly called Users, but there is no limit to the number of groups to which users can be assigned. Most
NOSs create a unique, encrypted system ID (SID) to identify the user. A system ID prevents confusion between users who might accidentally use the same logon ID. Duplicate logon IDs easily can be intercepted and prevented on a LAN. However, a user on a WAN
in San Francisco might unknowingly use the same logon ID as a WAN user in Sydney, Australia. Maintaining user accounts is one of the principal duties of network administrators.
There is little distinction between network administrators and users in workgroup environments. Workgroup networks are self-administered; any user can share files located in directories on his or her computer with other members of a workgroup.
Workgroups do not maintain user accounts. Therefore, files in any directory that are shared by a user are, by default, "up for grabs" by anyone else who is connected to the network. The user sharing files can restrict other users from modifying
the files by sharing the files in read-only mode and can require that workgroup members enter a password to gain access to files in the shared directory. The limited security offered by conventional workgroup networking environments has limited their
acceptance by IS departments of large firms. Using the Jet database security system with Visual Basic 4.0 applications (the subject of the next section) can overcome the security limitations of workgroup file sharing.
The peer-to-peer networking features of Windows NT 3.51+ provide an increased level of security compared to that offered by Windows 3.11 and Windows 95. Windows NT requires that you log on with a user ID and password, while logon IDs and passwords are
optional for Windows 3.11 and Windows 95. If you have administrative authority, you can assign users of individual computers to groups and then grant group authority to share your directories. The normal practice is to create a user group with the same
name as the workgroup. If you use the NT file system (NTFS) instead of the DOS file allocation table (FAT) system, you can grant users permissions on a file-by-file basis. The FAT file system, required by dual-boot installations that need access to the
same folders, restricts you to granting permissions to share entire folders. Using predefined groups and creating new groups, as well as granting directory and file permissions to members of groups, are subjects of sections later in this chapter.
Windows NT overcomes many of the objections of MIS managers to the lack of security within self-administered networks, but peer-to-peer networking remains a threat to the centralized authority (and in many organizations, the perceived status) of IS
departments. The likelihood of a large number of corporate PC clients running Windows NT instead of Windows 3.11 or Windows 95 (at least in the economic climate that prevailed at the time this edition was written) is quite small because of the expense of
upgrading PCs to meet the resource requirements of Windows NT.
One of the advantages of using Jet databases with Visual Basic 4.0 applications is that you can use the retail version of Access to implement database security with System.mda (Jet 2.5 and earlier) or System.mdw (Jet 3.0) in addition to restricting
access to the FileName.mdb file through network security. Jet uses the System.md? file to store group names, user IDs, passwords, and SIDs. When you add a new user to a Jet security group, you enter the user ID and a four-digit PIN (personal
identification number). (The PIN number distinguishes between users with the same user ID.) Jet combines the user ID and PIN to create an encrypted binary SID (system ID) value that is used by Jet .mdb files to identify each user who has permissions for
files that exceed the scope of default permissions (also called implicit permissions) granted to the group(s) to which the user belongs.
System.md? is used in this chapter and elsewhere in this book to indicate either the Jet 2.5 and earlier System.mda system file or the Jet 3.0 System.mdw workgroup information file. Jet 3.0 links (attaches) both 16-bit SYSTEM.MDA and 32-bit System.mdw files. If you must support users of both 16-bit and 32-bit .mdb files, don't convert your Jet 2.x SYSTEM.MDA file to a Jet 3.0 System.mdw file; Jet 2.x cannot link a 32-bit System.mdw file.
Using Jet database security features means that at least one individual should be appointed as a database administrator (DBA) to manage the user accounts in the System.md? file that is shared by members of one or more workgroups. You can use a
single System.md? file that is shared by all members of all workgroups, or multiple System.md? files, each of which is located in the folder that contains the .mdb file(s) that the workgroup members share. Workgroup members must have
read-write access to System.md? so that users can change their password periodically to enhance database security. Therefore, if you want to use network security to provide one group of users read-only permissions and to grant another group of users
read-write permissions, you should use the single System.md? approach and place System.md? in a directory to which all members of all workgroups have read-write network permissions.
Jet enables you to grant read-only or read-write permissions to groups and individual users for tables in the database; however, members of the Users group, by default, have read-write and modify permissions on all database tables. You need to
explicitly remove write (Administer, Modify Design, Update Data, Insert Data, and Delete Data) permissions for the Users group, and then assign write permissions only to authorized users.
You can specify a name other than System.md? for the security database or locate System.md? in a folder other than the one that contains the associate .mdb file(s), but doing so requires that you use the workgroup administration
application supplied with Access, or that you manually perform one of the following operations:
Details of the methods you use as the DBA for Jet databases used by Visual Basic 4.0 database applications are given at the end of this chapter. Jet database security is modeled on the security system of NTS, so describing network security prior to a
full discussion of Jet database security methodology makes Jet's labyrinthine security features (a bit) more comprehensible.
Windows NT Server has an extraordinary number of predefined groups of administrators and users. Table 18.1 lists the predefined groups that are created when you install NTS, those groups predefined by Windows NT 3.1 workstations, and groups of database
users defined by Jet. The rows in Table 18.1 are ordered by descending level of authority-to-administer and permission-to-use domain resources. The Domain Admins and Domain Users groups are global groups; the remainder of the groups are local to a specific
server computer. An "N/A" entry in a cell of the table indicates that the group is not available in the particular environment.
| NTS Domains | NT Workstations | Jet |
| Administrators | Administrators | Admins |
| Backup Operators | Backup Operators | N/A |
| Server Operators | N/A | N/A |
| Account Operators | N/A | N/A |
| Print Operators | N/A | N/A |
| Replicators | N/A | N/A |
| N/A | Power Users | N/A |
| Everyone | Everyone | N/A |
| Users | Users | Users |
| (Guests) | Guests | Guests |
The following list provides a brief description of the basic categories of predefined groups for NTS, NTW, and Jet databases:
Chapter 3, "How Network Security Works," in the Concepts and Planning Guide for NTS, provides a complete description of the rights and abilities of each predefined group and special entity of NTS and NTW.
NTS and NTW folders that are located on fixed disk partitions formatted as FAT (DOS) partitions can be shared on the network, but you cannot control network access to individual files or sub-folders of a shared FAT directory. To control access to
individual files, the files must be located in a folder of an NTFS partition. Most NTS server installations now use NTFS exclusively, but it's more common for NTW computers, especially those that dual-boot another operating system, such as DOS/Windows 3.11
and/or Windows 95, to use FAT partitions.
After you've gained experience with NTS and are fully confident of its capabilities, you can reformat the FAT partition to NTFS without losing the data the partition contains by running the CONVERT.EXE application. Make sure you back up the FAT partition before running CONVERT.EXE. You cannot change an NTFS partition to a FAT (or HPFS partition). Instead, you delete the partition, along with all of the data on the partition and then re-create the partition and format it as an NTFS partition. If NTS or NTW is located on the NTFS partition you want to reformat, you need to run the NT setup application to delete the partition.
Once you've added the NTFS logical drive (volume), you create the directory structure for the files to be shared by the server. Files in directories and subdirectories on NTFS drives can be assigned one or more of the permissions listed in Table 18.2
for individual users or groups of users.
| Permission | Abbreviation | Permission | Abbreviation |
| Read | R | Execute | X |
| Write | W | Change Permission | P |
| Delete | D | Take Ownership | O |
Table 18.3 lists the standard Windows NT permissions for shared NTFS directories. The Directory column lists the abbreviations of the permissions that apply to the directory itself, and the New Files column lists the abbreviations of
the permission for files that are added to the shared directory after directory-level permissions are granted. Permissions you assign to file and subfolder shares apply to users who log on to the server itself, as well as to users of workstations. Only
members of the Administrators and Operators groups are allowed to log on to the server with NTS's default security settings.
| Permissions | Directory | New Files | Description |
| No Access | None | None | A user cannot obtain access to the directory or its subdirectories. |
| List | RX | N/S | A user can list the files and subdirectories, but not read the files. |
| Read | RX | RX | A user can read and execute files in the directory (basic read-only access). |
| Add | WX | N/S | A user can add and execute files but cannot read or change existing files. |
| Add & Read | RWX | RX | A user can read and execute files in the directory but cannot modify files. |
| Change | RWXD | RWXD | A user can read, write, and delete files in the directory. |
| Full Control | All | All | In addition to Change permissions, a user can set permissions for and take ownership of any file in the directory. |
Table 18.4 lists the standard Windows NT permissions and the Jet 3.0 database file permissions applicable to Access Table and QueryDef objects that correspond to the Windows NT file permissions. Permissions that apply to Access forms,
reports, macros, and modules are not applicable to Visual Basic 4.0 database applications.
| Permissions | Files | Description | Jet 3.0 |
| No Access | None | A user cannot obtain access to the file. | No permissions. |
| Read | RX | A user can read or execute the file. | Read Definitions, and Read Data. |
| Change | RWXD | A user can read, write, or delete the file. | Read Definitions, Read Data, Update Data, Insert Data, and Update Data. |
| Full Control | All | A user can read, write, delete, set permissions for, or take ownership of the file. | Full Permissions, but the ownership of objects in the file requires importing objects into a new .mdb file. |
The Windows NT 3.51 File Manager is similar to that of Windows 3.11, except that an additional toolbar button with a key icon enables you to set file permissions for individual files on NTFS volumes. To assign permissions for a file or
a group of files, select the file(s) in File Manager's window and then click the File Permissions button to display the File Permissions dialog. Click the Add button of the File Permissions dialog to display the Add Users and Groups dialog. Figure 18.14
shows the Add Users and Groups dialog for file permissions. Double-click the names of the existing groups for which you want to assign permissions to add the name of the group to a semicolon-separated list in the Add Names text box. If you want to add an
individual user to the list, select the group to which the user belongs and click the Show Users button to display a list of users in the group.
Figure 18.14. The Add Users and Groups dialog of NTS.
A full description of NT and NTAS share security for both FAT and NTFS partitions is provided in Chapter 5, "Managing Network Files," of the NTS Concepts and Planning Guide.
As mentioned earlier in the chapter, the Jet database security system has been called labyrinthine, Byzantine, and even Machiavellian. The security methodology of Jet is derived from a mixture of LAN Manager, SQL Server, and Windows NT security
techniques. If you decide to implement Access security in conjunction with Visual Basic 4.0 database applications, or your Visual Basic database applications share secure .mdb files with Access applications, you must have a fundamental understanding of how
Jet implements security for Table and QueryDef objects. You don't need to worry about security issued for Access Form, Report, Macro, and Module objects, because Visual Basic does not recognize these objects. It is far easier to use Access to manage Jet
security features than to do so programmatically with Visual Basic 4.0. The sections that follow assume that you possess a license for the retail version of Access 95.
Before you use any of the security features of Access that are discussed in the following sections, make sure you make a backup copy of the System.md? file in use and back up any .mdb files whose permissions you plan to modify. If you have not
made any changes to the default values in the System.md? file that was installed when you set up Access, make a copy of the System.md? file on a diskette and save it for future use as the base System.md? file for creating new
applications.
When you first launch Access, you are assigned a default user ID of Admin, a member of Access's Admins and Users groups, with an empty ("") password. This combination of user ID and empty password prevents the Logon dialog from appearing when
you launch Access. If the Logon dialog (see Figure 18.15) appears when you launch Access, you may have the beginning of a secure database system. (This statement assumes that unauthorized users do not know the valid user ID and password combinations
contained in System.md?.)
Figure 18.15. Access 95's Logon dialog.
Access 95 provides a simpler method of implementing database security by password protection. If you password-protect a database, a dialog appears when you open the database requesting a password, which is common to all users. Password protection provides only a low level of security and you cannot use password protection with Jet 3.0 replicated databases. You can, however, use the full security system described in this section for database replication.
To initiate database security with Access, you need to add a new user ID and assign the new user account membership in the Admins group. After you add the new member of the Admins group and take ownership of the objects in the database(s) you intend to
secure, you can remove the default Admin user account from the Admins group (if other Access System.md? files do not depend on the presence of the Admin user), and take away all permissions from the Admin user. You also need to change the ownership
of any existing database objects created by the Admin user that you want to make secure. Follow these steps to secure Access 95 so that only DBAs can launch Access:
At this point, Access itself is secure and any new Access databases you create also will be secure. Henceforth, your new user ID is the owner of any new database objects you create. However, all Access database objects you and others previously created
with the Admin account (using the blank password) are not secure for the following reasons:
To secure database objects whose creation date precedes your securing Access, you need to take ownership of the database objects by importing the objects into a new database file. Traditionally, you change ownership of Jet database objects by importing
the objects into a new database, then removing permissions for the Admin user. Access 95 includes a new User-Level Security Wizard that handles the entire process for you. (If you are using an earlier version of Access, you might want to skip to the next
section).
Assuming ownership of objects in an existing Jet 3.0 database and encrypting the file for additional security require the following steps:
You now have a secure database in which you are the undisputed owner of all of the database objects. If Microsoft had made the Take Ownership (O) permission of Windows NT applicable to Jet database objects, the transfer of title would be a much simpler
process. However, an additional benefit of the User-Level Security Wizard is that the Wizard encrypts the secure database so that the data in TableDef objects cannot be read with a binary file editing application.
If your Visual Basic database application must run under Windows 3.11, you must use a 16-bit version of Access to implement security features. In this case, you create a new database (using your new account), and then import the objects into the new
database to change ownership from the Admin account to the new user account. The names of permissions in the sections that follow, such as Modify Data, are for Access 1.x databases. Access 2.0 databases use the same permissions terminology (Read
Data, Update Data, and so forth) described in the preceding section for Access 95.
By default, all versions of Access grant Full Permissions on all TableDef and QueryDef objects (as well as other Access database object types) to members of the Users group. Granting Full Permissions by default to the Users group has been the subject
of many complaints from Access developers. These complaints led to addition of the User-Level Security Wizard of Access 95. It is unlikely that you want everyone who can open the database to have read-write access to all or even any of the tables in the
database. This is especially true of databases that are the source of data for decision-support applications. (One of the canons of Database Administration is this: I shall grant no one with a title other than Data Entry Operator or Data Entry Supervisor
read-write permissions in my databases.)
Because all except the Guest user of Access databases must be a member of the Users group, you need to revoke Modify Data privileges from the Users group and create a new group, DataEntry, which has both Read Data and Modify Data privileges. (Everyone
with access to the database should be granted Read Definitions privileges.)
To revoke Modify Definitions and Modify Data permissions from the Users group for objects in Access 1.x databases, follow these steps:
Members of the Users group no longer have default (implicit) permissions to modify the design of tables or queries, or to update tables in this database. You can give specific members of the Users group Modify Data permission by listing Users instead
of Groups, selecting the user from the combo box, and ticking the Modify Data check box. Implicit permissions of users inherited from group membership do not appear in the check boxes when you display individual user permissions. (This is a peculiarity of
the Access 1.x security system.)
The process for revoking Group permissions is the same for Access 1.x and 2.0, except that the permission names differ between the two versions.
To create a new DataEntry group and set up the correct permissions for the new group, follow these steps:
Finally, don't forget to modify your Vb.ini and AppName.ini files to take into account the necessity of attaching the appropriate System.mda file to the newly secure Jet database(s) you open in your 16-bit Visual Basic database application.
Once you secure a Jet database, you must establish a pointer to the location of the System.md? file as described in the "Supplementing Workgroup Security with Jet's Security Features" section, earlier in this chapter. If you don't use
the Registry or an AppName.ini file to point to System.md?, your 32-bit Sub Main subprocedure or Form_Open event handler of your first form must include one of the following lines prior to any code that refers to the database:
DBEngine.SystemDB = "d:\path\system.mdw" DBEngine.SystemDB = "\\servername\sharename\path\system.mdw"
If you don't add this code (or the appropriate Registry or AppName.ini entry), the message shown in Figure 18.24 appears when you attempt to run your application that contains a reference to or a Data control based on a secure Jet database. If
Jet can't open the designated System.md? file, the message shown in Figure 18.25 appears.
Figure 18.25. The message that indicates an incorrect pointer to the System.md? workgroup file.
The first form must be a logon dialog that provides text boxes for entry of a user ID (account name) and password. You pass the value of the user ID and password to the DefaultUser and DefaultPassword properties of the DBEngine object with the two
following lines of code executed by the OK button of your logon dialog:
DBEngine.DefaultUser = txtUserID.Text DBEngine.DefaultPassword = txtPassword.Text
The user ID and password applies to the default Workspace object, Workspaces(0). For test purposes, you can add the preceding lines immediately after the DBEngine.SystemDB = statement with literal strings substituted for the text box values. If
you don't provide a user ID or password, or either the user ID or password is incorrect, you receive the message shown in Figure 18.26.
Figure 18.26. The message that indicates a missing or incorrect user ID and/or password.
An alternative to the Default. . . approach is to use the CreateWorkspace(strWSName, strUserID, strPassword) method of the DBEngine object and apply the Append strWSName method to the Workspaces collection. You then refer to the new Workspace object by a Set wsName = DBEngine.Workspaces(strWSName) statement.
Once you've opened the System.md? file, you have access to the Users and Groups collections of the newly created Workspace object. You can use the Debug Window to enumerate the members of the Users collection by typing ?
wsName.Users(i).Name. The names of the first three User objects (admin, Creator, and Engine) are provided by Jet for both secure and unsecured databases; the first secure User is Users(3), as illustrated by Figure 18.27. The first two members of
the Groups collection are Admin (0) and Users (1); the Group objects you add begin with index 2.
Figure 18.27. Iterating the Users collection of a secure database in the Debug Window.
Each Group object has a Users collection, which enumerates the members of the Group, and each User object has a Groups collection, which enumerates the Groups to which each User belongs. Figure 18.28 illustrates in the Debug Window the relationship
between Groups(i).Users(j) and Users(i).Groups(j). You add and delete members of the Groups and Users collections by applying the CreateUser, CreateGroup, and Delete methods. Only members of the Admins group can manipulate the
Users and Groups collections.
To add a new User object to the workgroup information file, you apply the CreateUser(strUserID[, strPID[, strPassword]]) method to the default Workspace object. Next, you Append the newly created User object to the Users collection
of the default Workspace and then Append the User object to the Users collection of at least the Users group, as in the following example:
Dim wsName As Workspace
Dim usrNew As User
Set wsName = DBEngine.Workspaces(0)
'Create the new user with a PID and password
Set usrNew = wsName.CreateUser("new", "1234", "bogus")
'Append the new user to the Users collection
wsName.Users.Append usrNew
'Append the new user to the Users group
Set usrNew = wsName.CreateUser("new") 'Recreate usrNew
wsName.Groups(1).Users.Append usrNew
'Optionally, append the new user to the Admins group
Set usrNew = wsName.CreateUser("new") 'Recreate usrNew
wsName.Groups(0).Users.Append usrNew
When you create a form to allow Admins members to add new users, your cmdOK_Click event handler should include addition of each new user to the Users group. You must recreate the User object each time you append the new User object to the Users collection of a Group object.
It's easier to experiment with the addition of new users in the Debug Window. Figure 18.29 shows the code of the preceding example with intermediate tests for Group membership.
Figure 18.29. Adding a new user to the Users and Admins groups in the Debug Window.
Permissions of Groups are inherited by members of Groups. Thus, a new user added to the Users group will inherit permissions previously assigned in the System.md? file to the Users group. You grant or revoke explicit permissions using the
Containers collection of the Database object and the Documents collection of the Container object. The Tables container includes both TableDef and QueryDef Document objects. Figure 18.30 illustrates experimentation with Container and Document objects for
an open database in the Debug Window.
Figure 18.30. Experimenting with Database Container and Document objects.
To gain access to the Tables container of an open database—the TableDef and QueryDef documents—and assign or revoke permissions to the Tables Container and each Document object, use the following code:
Dim wsCurrent As Workspace
Dim dbCurrent As Database
Dim cntTables As Container
Dim docTable As Document
Set wsCurrent = DBEngine.Workspaces(0)
Set dbCurrent = wsCurrent.Databases(0)
'Set the Container object variable
Set cntTables = dbCurrent.Containers("Tables")
'Establish the user ID and set Container permissions
cntTables.Inherit = True
cntTables.UserName = strUserID
cntTables.Permissions = intPermissionFlags
'Establish the user ID and set all Document permissions
For Each docTable In cntTables.Documents
docTable.UserName = strUserID
docTable.Permissions = intPermissionFlags
Next
Table 18.5 lists values and permissions (intPermissionFlags) for the intrinsic dbSec. . . constants defined by the Jet 3.0 DAO. As with other constant flags, you can combine various permissions with the bitwise Or operator.
| Constant Name | Value | Object Permission(s) |
| dbSecCreate | 1 | Create new documents (Container object only) |
| dbSecDelete | 65536 | Delete the object |
| dbSecDeleteData | 128 | Delete records |
| dbSecFullAccess | 1048575 | Full access |
| dbSecInsertData | 32 | Append records |
| dbSecNoAccess | 0 | No access |
| dbSecReadDef | 4 | Read TableDef or QueryDef object properties, but not data |
| dbSecReadSec | 131072 | Read security-related properties |
| dbSecReplaceData | 64 | Update records |
| dbSecRetrieveData | 20 | Read data |
| dbSecWriteDef | 65548 | Modify or delete TableDef or QueryDef object |
| dbSecWriteOwner | 524288 | Change the Owner property value |
| dbSecWriteSec | 262144 | Alter permissions |
One of the most fertile fields for Visual Basic database developers is creating applications that integrate shared-file and client/server database content into HTML-encoded documents designed for distribution on the Internet's World
Wide Web. Microsoft announced in December 1995 and January 1996 a multitude of Internet-related extensions to 32-bit Windows, plus SDKs for adding security and credit card transaction capabilities to Web browsers and servers. The following elements of
Microsoft's new "Internet Incentive" are of primary interest to Visual Basic database developers:
When this edition was written, all of the preceding elements of Microsoft's Internet strategy were in the beta stage(DocObjects, Internet Server, and ISAPI) or the definition stage (Internet OLE Controls and Internet Studio.) You can obtain up-to-date
information on and download early versions of Microsoft's Internet product line from http://www.microsoft.com/INTDEV/TECH.HTM. Unlike most of Microsoft's beta testing programs, which have limited distribution and require non-disclosure agreements,
pre-production versions of the Internet extensions to existing applications and 32-bit operating systems are available for public downloading. In early 1996, Microsoft was updating its Internet Developer Web pages at least once per week.
Microsoft has been accused of "missing the Internet boat" by many PC industry pundits. There appears to be no question that Microsoft underestimated the importance of the Internet as the "universal WAN," as well as the rate at which
organizations embraced the intranets and the Internet as means of disseminating information to employees and the public, respectively. Sun Microsystem's Java initially gained the public relations edge as the programming language of choice for creating
downloadable Internet applets. In the longer term, however, it's likely that VBS will prevail as the most popular World Wide Web programming language, both on the client and server sides. Today, there are between 1.5 million and 3.0 million active users of
VBA, depending on whose estimates you choose to believe. The ability of a million or two Visual Basic developers to leverage their VBA experience when creating interactive Web pages and server applications lends VBA the upper hand. Those new to programming
find Visual Basic a much easier language to learn than C++ and derivatives, such as Java. Just as VBA is the lingua franca of Windows application programming, VBS will emerge in 1996 as the Esperanto of World Wide Web programming.
This chapter has covered a great deal of territory—from an elementary description of PC networking systems, to the intricacies of security management with Windows NT 3.51 Server, to creating Jet databases that have both network and internal
security, and finally to the use of Visual Basic in Web browsers and servers. Although this chapter could have been divided into two chapters that separately discuss networking and Jet security topics, the relationships described between network and Jet
security methodology are an aid to a better understanding of Jet's security features.
The next chapter delves into the issues you face when you create front-ends for client/server RDBMSs instead of desktop databases. The 16-bit version 2.5 of the Microsoft ODBC API and SQL Server 6.0 under Windows NT 3.51 Server is used for the sample
applications in Chapter 19, "Understanding the Open Database Connectivity API."
