Test Generator for Database Management Systems

The present invention relates to electronic data processing, and more specifically concerns automated testing of database management systems.

Relational database management systems (DBMS), such as Microsoft SQL Server, interpret statements written in a database query language such as Structured Query Language (SQL) to create and manage database objects, to insert and update data, and to perform complex, multilevel queries against huge amounts of data. Testing these systems is recognized throughout the industry as a technical challenge of the first magnitude. SQL and similar database-system interpreters are highly complex. For example, they offer sophisticated optimization techniques and execution planning for queries input on the fly; opportunities for arcane design problems are ubiquitous. At the same time, the state space to be tested is gigantic. For a one-gigabyte database, the possible combinations of database configuration and SQL statement to be executed exceeds 10.sup.2,000,000,000.

Libraries of test scripts for relational database systems typically contain thousands or tens of thousands of sample statements which are applied to a test database for comparison of their results with known correct data. Existing libraries are known to be inadequate; most commercial database systems produce a constant and substantial stream of reported bugs. However, the amount of work required to generate larger libraries quickly becomes prohibitive. At the rate of a half hour per hand-written test statement, even a small library consumes more time than does the design of the system that it tests.

In the past, developers have employed some stochastic testing at the language level to accelerate database testing. For example, a test-case generator may choose a random mix of hand-generated fixed scripts. Choosing random parameter values in fixed scripts increases the effective number of test cases. These methods still require painstaking human composition and verification of long, multilevel queries. Automated generation of very simple queries considerably speeds up the generation of test cases, but eliminates the more complex test cases where subtle errors lurk.

In addition, conventional test systems are effectively limited to a fixed database, or to simple variations on fixed data. In order to construct statements that actually execute properly against the target database, the test system must be internally coded to produce only those statements that match the semantics of the database, the names of the database tables and their columns, the particular data types of each column, and so forth. However, testing on only one set of data obviously restricts the range of the tests that can be performed and thus the errors that will be uncovered. In addition, the use of fixed data for many tests does not permit slanting test runs toward certain kinds of applications, or focusing on the kinds of data or database structures that have been found to produce errors.

Also, the length and intricacy of test statements, although desirable for teasing out subtle errors, works against the isolation of bugs which cause those errors. Short, simple statements that produce errors are much more useful for tracking the errors down to particular parts of the DBMS under test.

The prior art is this field has not satisfied a longstanding need for very fast generation and manipulation of complex test statements for sophisticated database systems.

The present invention speeds up the generation of database test cases by orders of magnitude. A typical generator running on a personal computer having a single 200 MHz microprocessor outputs 700 SQL statements per second, about a million times faster than a human. The queries are complex and can have multiple nested levels. They have valid semantics as well as valid syntax; that is, they will run correctly on a bug-free database system, using whatever sample database is selected for a test run. The statistical and other features of the test cases are configurable. A test operator may choose the syntactic elements selectable in queries or other statements, the frequency of their use, and parameters such as the maximum subquery depth.

Briefly, the invention achieves these and other objectives by reading configuration data containing a set of test parameters, reading the schema of an arbitrary database, then constructing a number of test statements that are syntactically correct for the DBMS being tested, that are semantically compatible with the target database, and that have content and characteristics pursuant to the configuration data. One or more DBMSs under test execute the statements and return result data. Execution errors are detected, as well as result-data differences. Error-producing statements can be converted into greatly simplified statements that provoke the same error, in order to facilitate fault isolation.

Other features and advantages of the invention, as well as modifications within the scope of the invention, will occur to those having routine skill in the art from the following detailed description, taken in conjunction with the accompanying drawing.

FIG. 1 is a block diagram of an environment in which the invention can be practiced.

FIG. 2 is a block diagram of an illustrative database system to be tested by the invention.

FIG. 3 is a flow diagram for a test generator according to the invention.

FIG. 4, comprising FIGS. 4A-4F, shows a configuration file used in the process of FIG. 3

FIG. 5 shows an example of a syntax diagram used for constructing a statement in FIG. 3.

FIG. 6 is a flow diagram detailing the construction of a test statement according to FIG. 3.

FIG. 7 illustrates a state-information file for use in conjunction with an implementation of FIG. 6.

FIG. 8 shows an example of a parse tree for a statement constructed by the process of FIG. 6.

FIG. 9, comprising FIGS. 9A-9B, illustrates a more typically complex test statement produced by the process of FIG. 6.

FIG. 10 is a flow diagram for simplifying a faulty statement according to FIG. 3.

FIG. 11 shows a simplified version of the statement of FIG. 8 produced by the process of FIG. 9.

FIG. 1 is a high-level block diagram of a conventional client/server computer system 100. Network wiring 110 interconnects a number of personal computers (PCs) 120 to a server 130 via network adapters 121 and 131. Server 130 includes a storage subsystem 132 for holding the large amounts of data in typical enterprise databases. Other system architectures are also suitable environments for the invention; for example, units 120 may be terminals connected to a mainframe or midrange computer 130, or unit 130 may itself comprise a PC coupled to PCs 120 in a peer-to-peer network. For small databases, the entire system 100 may comprise a single PC acting as both client and server. Likewise, file storage may be distributed among a number of different machines. FIG. 1 includes a schematic representations of an external storage medium 133 which may store client and server software for distribution and downloading to clients, and another medium 134, such as a diskette, for offline storage of database tables. Medium 134 can also store instructions and data for the test program of the present invention; the test program can be executed in one or more of the clients 120, or even in server 130.

FIG. 2 is a block diagram of a typical conventional client/server database management system 200 capable of operating in system 100, FIG. 2. A client application program 210 executes within each PC 120, under a PC operating system 220 such as Microsoft Windows95. Among other functions, client application 210 contains a facility 211 for accepting database queries from a user at a PC 120. In addition to user entries, other application programs 230 executing in some of the PCs 120 may present queries to DBMS client 210, via predefined host-language application-program interfaces (APIs) 231. One of these programs can be the test program of the invention.

Within server 130, a DBMS server application 240, such as Microsoft SQL Server, executes under a server operating system 250 such as Microsoft NT. DBMS program 240 provides services for creating, maintaining, and modifying a number of relational databases, exemplified by database 260. Program 240 may employ the file-system services 251 of operating system 250, or may provide its own file system. Operating system 250 could execute a separate instance of the entire DBMS application for each request from a client 210. For greater efficiency, however, program 240 gives each client connection a separate thread 242 in the DBMS kernel. Further, this thread is a native operating-system thread, which carries with it all the Windows NT mechanisms for process memory protection, better access to storage devices, and so forth. Search engine 241 processes queries from individual clients 210 upon tables 261 of a database 260, as described more fully below. It also enforces database integrity with conventional facilities for record locking, atomic transactions, etc. In the Microsoft SQL Server, the interface language between query facility 211 and search engine 241 is Transact-SQL, which provides much of the function of the standard ANSI SQL 89 and ANSI SQL 92 languages, plus extensions for providing greater flexibility and programmability.

The test program may execute query-language statements upon multiple systems, either concurrently or sequentially. In order to differentiate between them, the reference numeral 240' indicates a second DBMS, which manages the same database 260 as the first system 240 (either at different times or, for some DBMSs, concurrently), or a different database, indicated as 260'.

FIG. 3 shows the overall flow of a test generator 300 for producing massive numbers of statements for testing DBMS applications 240 according to the invention. Test program 300 can reside in one of the PC clients 120, FIG. 1, where it may simulate a user; alternatively, it can execute within server 130, or at any other convenient location. Testing a DBMS in this context concerns checking the correctness of its implementation of the language by which it interfaces between databases and users of the databases. These languages are generally referred to as query languages, even though their statements perform many functions other than querying data in tables; for example, statements can create and modify data tables, insert and modify table data, define transactions for committing data, manage database security, and compile performance statistics. Likewise, the term "query" is usually used as a synecdoche for any statement in an interface language. This embodiment assumes the use of SQL (Structured Query Language), which is actually a family of more or less standardized dialects in common use. Any of these dialects will serve the present purposes. Other query languages such as QBE (Query by Example") can be substituted easily. Every query language has an explicit syntax specification that defines how to construct valid statements in the language. One aspect of testing the DBMS involves determining whether a statement that is well-formed according to the syntax of the query language does in fact execute without error in the tested DBMS (or, more generally, whether the DBMS reports the proper error status of any statement given to it). Another aspect involves verifying that the results (or lack of results) that a statement produces in that test database are correct. The present embodiment can perform both of these tests.

Preliminary blocks 310 begin the entire testing process. Block 311 reads in a configuration file 400 containing a set of parameters for the test procedure. One of the parameters specifies the name of a database 260 to provide the data tables 261. That is, the process is not limited to one or more fixed databases for testing a DBMS, but can employ arbitrary, user-selected target databases. Another parameter is able to specify the name of a different DBMS as a verification DBMS for checking the correctness of returned results. Other parameters of the configuration file will be described below.

Block 312 connects test program 300 to test DBMS 240 using the standard Open Database Connection (ODBC) protocol or any other conventional method. Block 313 determines the schema of the test database 240. The schema of a database is the organization of its data. Schemata for relational databases include the names of all data tables, the names, positions, and data types of table columns, restrictions on null or duplicate data values, and so forth. The test-database schema may be derived from any convenient source; it could, for example, be stored in the configuration file. Block 314 symbolizes the syntax specification of DBMS 240. In this implementation, the syntax is built into the code that constructs statements, rather than read in from an external source.

Block 320 constructs each statement to be used in the testing process as a parse tree by following the syntax specification of block 313. At each element of the syntax diagram, block 320 inserts a syntactic element which comports with the test-database schema read by block 314. The selection of one of a number of grammatically correct elements is made by a random roll from a seed, guided by probability parameters contained in the configuration file from block 311. The configuration file can, in fact, specify that only certain features, certain syntactical constructs, or certain parts of the database be included in the statements. Actually, block 320 produces statements using a pseudo-random number generator 321, so that the same configuration settings, the same schema, and the same starting seed cause it to produce the same statement deterministically; this allows regression testing of the DBMS. Although one could save the sequence of generated statements for regression testing, the advantage here is that saving only the starting seed can reproduce the entire sequence later. In addition, block 320 follows a set of internal rules that further permit or constrain certain choices at certain points in the parse tree.

Block 330 causes test DBMS 240 to execute the statement against database 260. If the configuration file had specified verification testing, then block 330' causes verification DBMS 240' to execute the same statement against the database. Each execution may or may not produce a set of data (for a query) or other results from the database. Verify block 331 compares the result sets produced by multiple executions, and produces a verify-error indication if they are not the same. Although the results could be compared in detail, a simpler check usually suffices; for example, block 331 can compare the number of affected rows for a data-modification statement. Block 331 can count the rows in the result sets of a query statement, then generate and compare checksums over the column values in all the rows; this avoids having to sort the result data and compare it one unit at a time. To avoid precision errors, the configuration file can specify a round-off tolerance for numeric fields. Date/time fields are more problematic, because the same value might assume different valid forms; a configuration parameter can specify a common format, or can specify that these fields are not to participate in comparisons.

Block 330 also produces an operational error indication when test DBMS 260 fails to execute the statement properly. Besides execution errors (usually including query-language compiler errors) reported by the DBMS, operational errors include lost connections to the database, deadlocks, and system crashes. If a DBMS connection is lost, program 300 attempts to reconnect; if this attempt fails, the program aborts the test run. A system crash requires an automated rapid restart of the sever in order to continue the run.

Block 332 logs each executed statement, its result data, and any error indications, along with the seed value for each statement. If verification is not being done for the test, logging this data allows the test to be run again at a later time in a pseudo-verification mode with the same DBMS 240, using logged data from the previous run for comparison. This mode is useful for catching suspected intermittent errors.

Blocks 340 process data and operational errors resulting from the execution of a statement. If no error occurs, block 341 passes control directly to loop control 350. The extremely long test runs generated by program 300 can result in huge error files of `uninteresting` errors. An uninteresting error is one that is expected to naturally occur in a randomly generated statement. For example, divide-by-zero and overflow errors are uninteresting. Therefore, block 342 filters some of these from the log, or merely counts their occurrences. Additionally, some errors tend to occur in large numbers when they occur at all. For this situation, a configuration-file parameter specifies certain error codes to count or to ignore entirely.

Block 343 simplifies statements which have produced errors. Debugging a complex non-procedural program such as a DBMS is greatly facilitated by modifying failed statements to produce simpler versions that still produce the same error. Simplification is particularly advantageous for the long, complex statements produced by program 300. Simplification proceeds by sequentially removing as many elements of the statements as possible while preserving the same error indication. The simplified statement is usually not equivalent to the original statement which means it would not return the same result set had no error in the system occurred. Although one bug might cause a certain error indication in the original statement and a different bug in the simplified one; this has been found to be extremely unlikely. Block 344 records the simplified statement and keys it to the original.

Block 350 passes control back to block 320 to generate another statement as long as the test run has not completed. Completion conditions are read from the configuration file. Any convenient measure, such as number of statements, number of errors, and run time, are possible. Block 351 draws up a report of the entire test run. The report can include conventional items such as error listings and statistics concerning the different types of features included in the test statements, or reduced summaries of such items. The report also optionally lists the schema of the test database and the current configuration-file settings. For the pseudo-verify mode described above, it is also useful to include machine readable information on each statement, its result data, and error indications. Program 300 can then run these same statements against the test database on the same test DBMS at a later time, and compare the two runs. Also, a conventional utility program can combine and summarize the results of multiple test runs carried out concurrently on different data processors.

This embodiment of program 300 generates and executes an entire suite of test statements in a single run. It is entirely possible, of course, to generate all the test statements in a batch, then to run those statements from a file at a later time. For example, program 300 could execute blocks 310, then loop on block 320 until all statements have been completed. Then a later run could loop on blocks 330-340, and print the report of block 351.

FIG. 4 shows a portion of a configuration file 400 containing about a hundred parameters that program 300 employs to control a test run. The format is similar to that of a conventional .INI file for specifying parameters and data to a program. Each line names a parameter and gives it value; comment lines begin with asterisks or dashes. A Program section specifies global parameters controlling the overall operation of a test run, including the database schema of block 313. The parameter fSimplifySQL determines whether or not to auto-simplify faulty statements. A Console section controls data display for real-time tracking of a test run. An SQLfile section configures the report file of block 351. A Limits section specifies bounds on database size, overall statement size, subquery depth, number, and so forth. An Allowed section controls the type and content of statements generated by block 320. For example, cSelList=8 ensures no more than eight output columns in any generated SELECT statement. Many of the parameters occur in pairs naming a maximum and a frequency for statement features or constructs. For example, cGroupByCols=3 and cWTG.sub.-- GROUPBY=25 specify that no statement has more than three columns in a GROUP BY clause, and that 25% of all statements shall include a GROUP BY clause. A group of parameters near the end of this section specify the mix of different statement types, such as UPDATE, INSERT, DELETE, and SELECT. Parameters such as fUnicode=0 toggle on or off the use of certain data types in generated statements. Frequently, discrepancies arise in block 331 of FIG. 3 because different DBMSs will return the same result data values but in different data types; data-type translation solves such problems without restricting the domain of generated statements. Because transactional integrity is an important aspect of DBMS operation, other parameters control the use of multi-statement transactions and methods, COMMIT and ROLLBACK, to end the transactions. Configuration file 400 not only permits the testing of different systems and databases, but also greatly facilitates the isolation of system bugs. That is, particular features and statement characteristics that produce problems can be emphasized merely by changing a few parameters in the file.

Program 300 builds statements in response to parameters from the configuration file, to database structure from the schema, and to the syntax of the query language. Query-language syntax is usually written as a set of productions in a stylized script or diagram format such as Backus normal form. A syntactically valid statement is conceptually constructed by expanding the productions, choosing only one of the allowable paths at every node where the syntax permits alternatives. In this embodiment, individual procedures build major productions such as WHERE and GROUP BY; the smaller productions, such as picking operators in an expression, employ simple case statements.

Some of the alternatives can involve repetitions and/or recursive calls. As an illustration of a syntax specification, FIG. 5 shows a partial set of productions 500 for a SELECT statement in a simplified dialect of SQL. The name of each production is printed above its diagram. Rectangular boxes indicate other productions. Rounds and ovals indicate terminal syntactic elements. Small diamonds indicate points at which alternative paths exist.

In Select Statement production 510, for instance, block 511 requires that a SELECT statement begin with the word "SELECT", which can be optionally followed by a qualifier word "ALL" or "DISTINCT" at point 512. Then a Select List Entry 520 can be repeated zero or more times at node 513, separated by commas. Production 520 for a Select List Entry comprises either one or more Column Name syntactic elements 521 separated by Operator elements 522 at choice point 523. Alternatively, point 524 can specify a Function name 525 followed by a parenthesized Column Name 521.

The final exit from node 513 following the last Select List expansion requires a "FROM" keyword terminal 514 followed by a Table List Entry 515; the production for this element includes table names, JOIN operators having ON clauses, and other elements, not shown. The other major parts of a SELECT statement are the optional WHERE clause 516, GROUP BY clause 517, HAVING clause 518, and ORDER BY clause 519. Both clauses 516 and 518 include a Search Condition predicate 530. Production 530 illustrates another aspect found in most syntax specifications: a production may include itself as an element, as shown by parenthesized block 530. Among the numerous elements available at node 531 is an Exists Predicate 540. Production 540 reveals that one of the elements of this predicate is a Select Statement production 510. That is, an entire SELECT statement can be nested inside another SELECT statement; such a nested occurrence is referred to as a subquery, and its containing query or subquery is called an outer query. A column C belonging to a table in an outer query can be referenced in a subquery. The reference to C in the subquery is called a correlated reference.

FIG. 6 shows a process 600 for constructing a single test statement according to block 320, FIG. 3, by following syntax diagrams stochastically. One may think of constructing a statement as building a parse tree of the statement; however, routine 600 does not produce any explicit representation of a parse tree. In the following description, the term "roll" means to obtain a number from random number generator 321 and use the number to make a choice among alternatives allowed by certain constraints, with probabilities which might be specified by rules, settings, or other sources; it includes situations where the constraints, etc., might allow only a single choice.

First, block 610 rolls to determine the type of statement to be generated. For the SQL query language, the alternatives include SELECT, UPDATE, INSERT, etc. Configuration file 400 lists the desired probabilities of each statement type. Block 611 initializes information described below that is carried along from node to node during the process.

Block 620 follows the syntax diagram of the selected statement. That is, at each activation, it chooses the next syntactical element or set of alternative elements in the diagram as the current node. In diagram 500, for example, block 620 would first choose element 511, then the alternatives presented at point 512, then, depending upon a roll outcome, neither or one of the elements 521 and 525, etc., then onward through diagram 520. Returning to diagram 510, a roll at point 513 sends block 620 through element 520 again, or on to element 514. Some elements might be visited recursively and/or repetitively as block 620 travels upward and downward through the diagrams 500. Block 621 outputs a representation of the statement to program 300 as the statement is generated. If the statement will be executed, block 621 also places a copy in a buffer.

In general, process 600 works on one syntactic element at a time to build one node of the parse tree. At certain places, however, it is necessary to gather preliminary information and to make certain preliminary choices involving elements other than those at the current node in the diagram. For example, the names of the tables to be used in a SELECT query need not be determined syntactically until block 620 reaches element 515 in FIG. 5. However, the choice of columns at previously encountered element 520 could provoke inconsistencies with certain constraints, such as parameter values in configuration file 400 or the schema of the database. Therefore, block 630 obtains any preliminary information specified for the current node, block 631 rolls any choices specified by the information, and block 632 records choices that might be useful or might affect choices further along the tree. Continuing the above example, when element 520 becomes the current node in a SELECT statement, block 630 retrieves the list of tables from the schema and the maximum number of tables in a join parameter from configuration file 400. Block 631 chooses a list of particular tables randomly within the parameter limit, and reads the names and data types of all columns belonging to these tables. Block 632 records the names of these columns, because this choice affects the alternatives available to the subsequent element 515, and also to other elements, such as the Column List of GROUP BY clause 517. As an added optimization, block 632 also records the data types of these columns in order to avoid having to look them up again while processing subsequent elements involving functions of those columns.

Block 640 gets information pertaining to the current node that can affect the alternatives available at that node. State information such as the identity of the present element in the syntax diagram obviously affects this choice. Certain parameter values in configuration file 400 might be relevant to the current node; for example, the maximum subquery depth might bar the choice of element 540 at point 531 in FIG. 5, because this element always generates a subquery at element block 510. Some of the preliminary choices might affect the current choices; this includes new information recorded by block 632 for the current node and for any higher node that may affect the current choice. For instance, the preliminary choice of less than all tables, made at element 515, precludes later nodes from choosing columns in other tables of the database schema.

Block 641 presents a cumulative history of previous choices made for any previous nodes in the parse tree. In building a tree by doing a walk of the tree, previous choices can affect subsequent alternatives at the current node. For example, the data type of an expression is chosen before the expression is generated so the data type information is passed down the tree. This is true even when the alternatives might be syntactically correct; for instance, an ORDER BY entry can be an integer to index the select list but the integer value can not exceed the number of elements in the Select List. The difference between blocks 640 and 641 is that the first restricts alternatives at the current node based upon determinations made for nodes higher (toward the root) in the constructed parse tree, while block 641 carries choices made at lower (toward the leaves) nodes upward to restrict choices when the current node is higher in the tree and choices made at sibling nodes in other subtrees of the parse tree. Stated another way, block 641 concerns all the node choices made up to the current node that are not in the path from the current node to the root. Carrying the results of choices to higher nodes is one of the most important factors in constructing semantically correct test statements for arbitrary databases according to the invention. Without a facility for carrying previous choices upward in the tree, process 600 would have to cleave closely to a predefined fixed database in order to construct statements consistent with the semantics of the database.

Block 642 makes available a set of rules written for particular nodes. These rules are of two types. Mandatory rules require the performance of certain actions. For example, some points in a syntax diagram require that a column reference be generated; thus any potential alternatives at the current node that do not result in a column reference must be excluded. Optional rules permit certain actions. Such a rule might allow the generation of a column reference to a correlated column in a subquery at the current node. Rules can be hard-coded into a program that executes process 600, stored in an external file, or implemented in any other convenient manner.

Block 650 assembles a list of alternatives available at the current node. These alternatives arise from the set of elements specified at the current node of the syntax diagram, and are potentially modified or restricted by some or all of the information obtained in blocks 640-642. Block 651 rolls the assembled alternatives to produce a random choice of a syntactic element for the current node. (As a shorthand notation, the term `roll` means to choose among a set of alternatives in accordance with a random or pseudorandom number; the probabilities of each alternative can be equal or weighted.) This can include a terminal value; e.g., a roll might produce the numeric value 10000 where the current node requires an item of numeric data. Some of the alternatives might have probabilities or ranges specified by weighting parameters in the configuration file, as mentioned. Although the roll outcome could be derived from a non-predictable random source, such as hashing the time of day, using a pseudo-random roll allows a seed value recorded in the configuration file to reproduce the action of block 651 deterministically if desired for regression testing or other purposes. For degenerate nodes where only one alternative exists, block 651, or blocks 640-650, can be entirely bypassed to save time.

Block 652 records the choices made in the history obtained by block 641. Block 653 updates the information obtained by block 640, based upon the current-node choices. Block 654 updates the statement according to the choices made in block 651. Normally, a choice at each current node adds a term to the statement's parse tree. However, it is sometimes advantageous to delay this action. For example, column references are constructed for a GROUP BY clause 517, FIG. 5, but later choices can generate expressions and intermix them randomly with the column references before outputting the clause as part of a SELECT statement or subquery.

In practice, process 600 can be implemented as a number of individual functions called recursively on a parse tree. As an example, a C function GenSelect() produces a single SQL statement 510 at any level of a parse tree. Briefly, this function first rolls to determine the list of tables in the FROM clause, within the configured limit. If this query must return a particular data type, it checks to ensure that at least one listed table contains a column of that type. Next, the function builds a list of data types for all columns in the selected tables. Another roll determines how many elements the select element 520 will contain. The next roll determines whether the query will include a DISTINCT clause, and/or will use the DISTINCT qualifier in aggregate functions. A roll includes or omits a GROUP BY clause, and, in the former case, rolls to build its column references--but does not yet output the clause.

The next step is to output the "SELECT" keyword to the tree, and start following syntax diagram 500. A sequence of rolls generates expressions for syntactic element 520 which are then output. The keyword "FROM" and the list of tables in the FROM clause is then output to the parse tree. If outer joins are configured, a sequence of rolls generates their ON-clause predicates. A roll includes or omits a WHERE clause 516, and performs further rolls to build it. If a predicate involves a subquery, GenSelect() produces certain rules (e.g., return no more than one row of data), and calls itself recursively to build the subquery. The function then produces expressions for the GROUP BY list, and outputs the entire GROUP BY clause. A further roll possibly includes and builds a HAVING clause, building any subqueries and their rules as above. Finally, a roll possibly includes and builds an ORDER BY clause, then rolls to intermix expressions and index references to entries in the Select List.

Another function, GenExpr(), builds expressions for GenSelect() and for other functions. It outputs a constant or a column reference, or calls itself recursively to generate operators or functions that take expressions as arguments. While the design of such a function is conventional, this particular expression builder illustrates the use of rules according to the invention. A call to GenExpr() includes two parameters. TableInfo holds the names and data types of table columns, as described above. ExprInfo contains the explicit rules that the expression must follow, and includes state information that influences the function's choices for expression terms. FIG. 7 lists the parameters of the ExprInfo rules and their meanings. Element names beginning with `f` are binary flags. If set, the corresponding rule must be followed The rule element DataType, e.g., is a mandatory rule enforcing a particular data type resulting from the evaluation of the expression, while fLocalFunctions is an optional rule allowing aggregate functions such as AVG() for any column contained in a table in the current FROM clause.

FIG. 8 shows an example of a parse tree 800 for a very short SELECT statement, as generated by process 600. The root of the tree is the SQL keyword "SELECT", 810. The next level of the tree has branches to three nodes. Although block 820 of the select list 520, FIG. 5, is grammatically the first node, process 600 proleptically produces a pool of possible table and column names, as described above. Block 820 specifies that the name column of the database's employee table is the first item in the list. The second item in the Select List is an expression, the sum 821 of columns named salary 822 and commission 823. Nodes 822 and 823 are leaf nodes; that is, their contents specify terminal elements in the syntax of a SELECT statement. The second high-level tree branch leads to node 830, the keyword "FROM" for table list 515. The only table included in this statement is employee, at leaf node 831. Again, process 600 had chosen this table, before actually outputting nodes 820-823; therefore, the column nodes in 820-823 were restricted to be columns of the employee table.

The third high-level branch specifies a WHERE clause at node 840. Nodes 841-847 constitute a predicate generated by a call to a function GenPred( ). Node 841 defines this predicate as a logical AND of two subpredicates. Nodes 842-844, generated by a recursive call to GenPred(), define the first subexpression as the condition that the value of the salary column exceed the numeric constant 10000. Nodes 843 and 844 are generated by calls to GenExpr(). The second sub predicate, nodes 845-847, specifies rows of the employee table where the department column contains the string constant "sales". Had the state information produced during the construction of node 831 not noted that at least one of the columns of the chosen employee table has a numeric data type, all arithmetic operators would have been dropped from the list of alternatives during the construction of the expression at nodes 821-823, which would have precluded the choice of addition operator 821. (Relational operator 842 and equality operator 845 are compatible with most data types.)

Process 600 builds statements in the form of parse trees such as 800. However, program 300 normally outputs test statements in the same form that a user or another program would input them to DBMS 240, FIG. 2. Therefore, output block 621 in FIG. 6 outputs each statement as an equivalent character-based representation. Parse tree 800, for example, becomes the statement:

SELECT name, salary+commission

FROM employee

WHERE (salary>10000) AND (department=`sales`)

FIG. 9 shows a more typically complex SQL statement generated by process 600 for a publishing-company database. Statement 900 nests subqueries up to five deep, and the inner queries reference correlated columns in the outer queries. Although some of the requests may seem a bit bizarre (e.g., royalty amounts expressed in radians), the statement syntactically follows the DBMS query language, and the requested data comports semantically with the rules of SQL and with the schema of the target database. Indeed, some of the more prolix constructs, such as adjacent minus signs and redundant parentheses, frequently provoke design errors that more usual statements overlook. One might think that such complex statements would rarely produce any result data at all. Experience has shown, however, that about 50% of non-error SELECT statements generated by process 600 do return at least one row of data. The maximum join size together with the database size and structure (schema) strongly influence the number of returned rows. For large databases, the maximum join size and the maximum subquery depth should be kept low in order to avoid excessive run times and system limits. In a sample test run, ten different clients 120, FIG. 1, concurrently executed 25,000 SQL statements equally distributed over SELECT, INSERT, UPDATE, and DELETE types. Expected errors (mostly deadlocks) occurred in 3,464 statements. Unexpected errors (bugs) having two different error codes occurred in a total of eighteen statements.

FIG. 10 shows a process 1000 for simplifying an error statement (that is, one which has produced an error indicating a fault in DBMS 240) according to block 342, FIG. 3. Because SQL and other query languages are non-procedural, and databases frequently contain gigabytes of data, the query compiler of DBMS 240 attempts to reduce processing time and memory usage with complex access plans involving many steps. Debugging the complex plans step by step is extremely tedious and difficult. Therefore, finding a simple statement having the same error as a much more complex statement aids greatly in isolating the cause of the error.

Block 1010 first reads in the error statement detected by block 341 in the format of a parse tree as shown in FIG. 8. Block 1011 records an indication denoting the particular error that occurred; usually, this is a code produced by search engine 241, although it can also be a signal indicating a connection loss, or some other indication. Block 1012 initializes process 1000 to the root node of the parse tree (e.g., node 810, FIG. 8).

Block 1020 walks the parse tree of the error statement, using any conventional method. Block 1020 chooses certain nodes whose subtree is a candidate for removal. Block 1030 removes the entire subtree of the current node. (For some cases, such as expressions involving two operands such as `A+B`, block 1030 first removes subtree A and also the `+`. Then it removes subtree B and also the `+`.) Block 1031 then reexecutes the truncated statement on the search engine. If the search engine returns the same error indication, block 1032 passes control to block 1020 to determine whether this truncated statement can be further simplified by removing additional subtrees. If the reexecution results in no error code, or in a different error code, block 1033 restores the subtree removed by block 1030 before passing control back to block 1020. When block 1020 has visited all branches of the parse tree, block 1021 translates the truncated tree into the form of a simplified statement and outputs it to block 344, FIG. 3.

Using the example in FIG. 8, block 1020 first visits the branch to node 820, to remove the subtree including nodes 820-823, then the branch to node 821, to remove nodes 822-823, then to remove 822 alone, then to 823 alone. Next, the branch to node 830 is removed, and that subtree is followed to its leaf 831. Finally, the branch to node 840 is removed, and its subtree is visited. Although the parse tree of the original statement could be processed in the opposite direction, walking the branches from the root node toward the leaf nodes removes the highest possible subtrees first, thus isolating the miscreant subtree more quickly. Also, block 1020 need not attempt to remove each possible subtree of the parse tree. For example, removing the entire subtree 820-823 would result in a simplified statement having incorrect syntax, because the entire select list would be missing from the SELECT statement. Block 1032 would then reject the resulting syntax-error code, causing block 1033 to restore the subtree. Removing the subtree containing nodes 821-823, however, leaves the statement in a syntactically correct form. (FIG. 8 has been simplified for this short example. For more complex statements, removing a subtree does not remove a suffix of the Select List. Select List entries are not removed, but rather only elements of their expressions. In expressions with two operands, the operator is removed along with the subtree of one of the operands.)

A more intelligent block 1020 understands at least some of the formalities of the target query language, and passes over branches which are known to be syntactically required or to possess other properties rendering them unsuitable for deletion. A number of heuristic optimizations have been incorporated into the statement simplifier. For example, it performs trial deletes from the top of the tree down; this alone eliminates the processing of most of the subtrees. The simplifier does not try all possible deletions. For example, it does not lop items from the Select List or from the ORDER BY list. It does not always plumb the deepest level. It never back-tracks. Once it tries a delete and finds it doesn't work, it never tries the same delete again, although there are cases where other successful deletes enable a previously tried one.

FIG. 11 shows a simplified statement generated from the statement of FIG. 8 by process 1000. Such drastic parings of the parse tree are not uncommon. Modifying elements of the simplified statement for further fault isolation is now feasible, whereas modifying portions of the full statement of FIG. 4 would be a daunting task.

Some possible modifications and extensions within the spirit of the invention have been described and suggested above. A major possible area of expansion involves checking performance. For example, most DBMS return estimates of execution time and amount of data that might be returned by a statement. The method of FIG. 3 has been be modified to read those figures and compare them to actual values computed during execution of the statement. In addition, parameters could be added to the configuration file for many purposes, such as to restrict statements to particular desired forms.

Further modifications within the scope of the following claims, as well as additional advantages of the present invention, will appear to those skilled in the art.