InformationWeek

Feburary 1, 1999

A Database Strategy For Newer Notebooks Only

By Andy Feibus

ncluded on the SQL Server 7 compact disc is a copy of SQL Server 7.0 Desktop edition, a database engine that's similar to its bigger sibling but supports Windows 95 and 98. This support, combined with the new merge replication feature supporting replication between disconnected sites, theoretically provides Microsoft with a database strategy for businesses that support mobile database users (Nov. 3, 1997, p. 77; www.informationweek.com/ 655/55oldbs.htm).

I use the word theoretically because although Microsoft's entry will work on a notebook computer, the memory and CPU demands of the product are geared toward newer and higher-end hardware. Microsoft says you can run the desktop server on any system with 32 Mbytes of RAM and at least a 166-MHz Pentium CPU. A slightly slower CPU--say, 100 MHz--worked fine in my tests.

However, systems with limited RAM are another story. Although the Desktop server can be configured to use as little as 4 Mbytes, I couldn't shrink the SQL Server 7.0 server process below 6 Mbytes--the whole set of processes still ran around 8 Mbytes. However, most database applications will use another 16 Mbytes or more of RAM to load all the essential Windows code for a user interface and other processing. Since Windows 95 and 98 require at least 16 Mbytes of RAM to run with normal performance, that makes for a tight fit. Performance won't be horrible on a 32-Mbyte system, but it won't exactly be fast, either.

Only a few higher-end features are missing in the Desktop edition: support for multiple CPUs, full-text searches, online analytical processing support, parallel queries, and some of the new optimized query features. Merge and snapshot replication are completely supported, although you can subscribe to transaction replicas only from the Desktop edition. You can't run English Query on the same system as the Desktop edition either, according to Microsoft's licensing agreement; technically, though, the two packages do work together.

As a database engine, though, the Desktop edition works fine for limited-user applications. However, you can obtain this piece only by purchasing the full SQL Server 7.0 package; you're then allowed to install the database engine only on systems with SQL Server 7.0 client licenses.

Installation is not optimized for deploying on thousands or even hundreds of desktop or mobile systems. The SQL Server 7.0 architecture requires that the desktop/mobile system be connected to the network server for initial installation. Partitioning the data for each system is also not simple for deploying to a large number of remote systems; you can subset the data based on the name of the remote system, but this technique has no real shortcuts like those you'll find in mobile replication schemes from Sybase and Oracle.

Once the replication configuration is created on the server, the desktop/mobile system administrator must create a blank database of the correct name, connect to the replication publisher, and then request that replication begin. On first connection, the database partition configured for the mobile/desktop system is transferred; subsequent replication jobs transmit only the changes since the last replication job.

Communicating changes from the desktop/mobile system to the replication distributor or publisher systems must be performed using a direct connection. The File Transfer Protocol can be used only to initially "publish" the database to anonymous subscribers. Using E-mail to communicate changes with mobile users is not supported.

Overall, Sybase SQL Anywhere 6.0 is far easier to deploy, has more-flexible communication schemes for transmitting replicated information to remote systems, and--if you stay away from using SQL Anywhere's new Java features--has significantly smaller RAM requirements, making it the better choice for mobile database users.

Return to main story, "SQL Server 7.0: Room To Grow"