At first, it's tempting to confuse the Active Server Pages approach with the ADO approach; both approaches result in the creation of an ADO
. However, the two approaches differ in two regards. With the ASP approach, the Recordset
is created using the Recordset
and Query
objects. With the ADO approach, the Utility
is created using some combination of the Recordset
and Connection
objects. More importantly, the query that you use to perform an ASP search consists of some combination of Index Server query language statements. The searches that you execute using ADO consist of SQL statements, which usually incorporates several of the unique features of the Index Server.Command
Having now messed around with the Index Server at some length, here's the conceptual shortcut I've found most useful: Think of the Index Server as a database, such as SQL Server or DBASE, a powerful engine that can process complex queries and return what amounts to a result set. Throughout this chapter, as we examine each feature of the Index Server, we'll do so with reference to this analogy. A database consists of tables of data, and these tables consist of discrete fields in which various types of information are stored.
To get at this information from within a program, you generally have to be acquainted with a query language designed to identify the information in which you are interested. After you execute this query against the database, you get back rows of data that (hopefully) mirror what you were hoping to find.
The Index Server is intentionally modeled after the ODBC approach to data retrieval. Within this model, a common language (SQL) can be used to retrieve data from any number of databases, provided that an ODBC driver for the target database is installed on the client system. To the user, the actual source of the data, whether SQL Server, MS Access, or an Excel spread sheet, is transparent. This transparency enables the user to focus on the data, instead of on the proprietary format in which the data is stored or on the functional peculiarities of any particular database.