Network Computingwww.networkcomputing.com

The Web has made data access commonplace. Nearly every Web server and Internet application product has some sort of data-access capability. You probably have products in your IS l ab right now that let you extract data to a Web page in some fashion. The problem is finding the right mix to suit your various application needs.

For general-purpose Web data access, you need products that are suitable for ad hoc applications--for example, when a department has "a chunk of data" in a table that it would like to share. If you apply the 80/20 rule, Web data-access products should let you satisfy 80 percent of the information requests without your having to delegate a contingent of developers to a corporate application.

On the other hand, if you have a custom enterprise application or a specific platform, your best bet probably is to turn to your specific application vendor. If you need a comprehensive human resources application, you should talk to your developers.

The Canned Variety The data access we're referring to often includes the Web server itself. For example, Microsoft Corp. includes its Internet Database Connector (IDC) and Active Data Objects (ADO) with the latest release of its Web server. ExperTelligence does the same with its WebBase. These produc ts both are functionally equivalent to a server-side HTML markup Common Gateway Interface (CGI) program, but they're built into the Web server.

Data access also has moved directly into Web development tools. Bluestone Consulting's Sapphire/Web is a sophisticated application development environment that supports Open Database Connectivity (ODBC) as well as native access to Oracle, Sybase and Informix DBMSes.

You need to ask yourself if the data-access services these products provide are sufficient, and, more important, if they fit the data publishing model you want to use.

The products listed in the Buyer's Guide charts beginning on page 153 fall roughly into four categories for data delivery: server-side HTML markup, schema publishers, stored procedures or procedural languages and search engines. Because server-side HTML markup allows the most flexibility, it is the most common approach to getting the data out. Wi th this method, you can write an HTML Web page as you usually do and you can include extended HTML markup tags that specifically encode database queries. The Web page then gets preprocessed by the server-side program, replacing query output with real data. It can involve a good deal of programming, but, fortunately, the syntax has a very intuitive HTML feel to it. We've found this solution best fits the needs of most network managers. It offers the most flexibility with the easiest interface to use.

Schema publishers usually come with a modeling program that lets you pick the specific tables and views you want users to see and set security accordingly. A custom CGI accesses a gateway, locally or remotely, that publishes these schema views to dynamically generate and format an HTML view of the published table. The setup lets you produce browsable views of your tables without having to write any code. Many data-access products talk about dynamically generating HTML pages: Schema publishers do it in the trues t sense. However, we've found that schema views are the most affected by performance problem s. But they offer a high-level development environment that often can model existing applications. Most other data-access tools require a good deal of coding even for existing applications.