System and method for browsing database schema information

[0002] The present invention relates, in general, to databases and methods for accessing such databases with query objects, and, in particular, to apparatus and methods for interactively examining database information, including database schema information, for the construction of query objects.

[0003] Databases represent an important data processing area in many applications. They are often used to store large amounts of information and then efficiently retrieve selected portions of the information. Many present day systems use a client/server database approach in which application programs running in clients access a central database management system (DBMS) located in a database server. In order to efficiently access the information in the database, the clients form queries which request information with selected characteristics. The queries are transmitted to the DBMS server which retrieves the desired information which meets the characteristics specified in the query. The results (commonly called a “result set”) are returned to the client.

[0004] Presently, such database environments are predominantly based on a “two-tiered” model consisting of a top tier containing one or more applications which generate queries that access the DBMS server in a bottom tier. The two-tiered model suffers from several drawbacks. First, the queries must be formulated in a specific query language, which is accepted by the DBMS server. While standard query languages exist, such as the Structured Query Language (SQL), specific DBMS query languages are often non-standard as a result of proprietary extensions made to the basic SQL query language. As a result, application programs written to generate queries in a particular query language are often not portable between different DBMS servers.

[0005] In addition, in order to generate the queries in the first place, each application developer, and, in some cases, the ultimate user, must understand the mechanics of the database, including the relationship of the files and tables therein and any relationships in the data required by the database organization. These relationships are commonly referred to as “business logic” since the relationships are typically based on shared business processes, practices and policies. Therefore, many parties must learn the business logic in order to generate meaningful queries.

[0006] Further, commonly-performed routines are typically replicated in each application program even if the application programs operate within the same business environment because each application functions autonomously from other applications. This replication results in poor code re-use and maintenance problems if the replicated routines must be changed.

[0007] Consequently, there is a trend towards using a three-tiered model for database environments. Generally, the top tier in such a model consists of clients containing the application programs and the user interfaces, the middle tier consists of code that embodies the business logic and the bottom tier consists of the DBMS servers which contain the data. In this model, the applications are implemented as “thin” clients, all of which interface with the business logic by means, of a common interface which does not involve knowledge of the business logic. The commonly-performed routines are all consolidated into the middle tier as part of the business logic. Since the business logic is shareable between the clients, code replication is avoided. The Common Object Request Broker Architecture (CORBA) presents one object-oriented approach to forming a three-tiered database environment, such as described in R. Orfali et al., “The Essential Client/Server Survival Guide,” pp. 375-458, John Wiley & Sons, Inc. (2d ed. 1996), the disclosure of which is incorporated herein by reference.

[0008] Several prior art methods of implementing the three-tiered model exist, however, most existing DBMS access mechanisms arid tools, including fourth generation languages (4GLs) and application programming interfaces (APIs), have been designed for the two-tiered model and are ill-suited for use in the three-tiered model. Consequently, several prior art designs including “database” objects and “active data” objects have their own strengths and drawbacks. One promising prior art approach to constructing a middle tier containing business logic uses “query objects.” Each query object is a server object that:

[0009] (1) translates client method invocations into equivalent queries in a query language which is understood by a database;

[0010] (2) issues those queries to the database; and

[0011] (3) returns the results as strongly-typed data values.

[0012] The query object effectively encapsulates the DBMS specific query language so that the application programs do not have to know or use the DBMS query language. Query objects also encapsulate the database organization or “schema”, so that query object clients are isolated from database changes (although the query object itself may have to be changed if the underlying database must be changed.) Query objects also present their clients with a DBMS independent API, for example, CORBA defines an Interface Definition Language (IDL) interface. They do not require that the data be mapped into objects as is the case with active data objects so that significant performance advantages can be obtained and concurrency issues avoided.

[0013] Each query object provides as part of its interface one or more parameterized methods and calls on each method are translated by the query object into one or more standard queries such as SELECT, UPDATE, INSERT and DELETE, or into initiation of one or more stored procedures in the database. In order to use the query object, a client first establishes a connection to the query object via some mechanism, such as the CORBA naming service. One of the query object's methods is then invoked and the query object then executes the query.

[0014] However, in order to operate properly, the query object must be constructed to generate the correct DBMS queries in response to client requests. Otherwise, the query object may operate as designed, but produce results which are not intended. Constructing a query object to generate the correct queries requires a knowledge of SQL, an understanding of the underlying database schema, the possible handling of intermediate results generated by the query and interpretation of the results. In addition, a query object developer must consider other issues such as connection to the database using CORBA or similar arrangement, concurrency problems and translation required between the interface used by the query object and the API used by the database. Consequently, tools have been developed to automate the generation of query objects. Some tools can generate a query object from a query described in conventional SQL language which is entered, by a user.

[0015] However, even with such tools, it may be necessary to understand the schema of the underlying database in order to correctly construct the initial SQL query and map the SQL query into the query language used by the underlying database. Since the database schema is related to the business logic, it is therefore, necessary to understand the business logic at some level. At the very least, the query object developer must obtain the names of tables and stored procedures in the database and their descriptions, including column names and types for tables and input and output parameters for stored procedures. For a particular query, it is also necessary to obtain a description of the result set produced by the query, including numbers and types of result expressions as well as possible bounds on the result set.

[0016] Further, the underlying database may use vendor specific data types which do not directly match the standard data types used in SQL expressions. Consequently, it may be necessary to first translate the data types before the query can be used. While these translations are well-known, they can be time-consuming details which distract the user from other, more important work.

[0017] Therefore, there is a need to easily obtain and display the database schema and automate testing of the query object, especially objects created with automatic generation tools. There is a further need to test query objects with actual data.

[0018] The foregoing problems are solved in one illustrative embodiment of the invention in which a query object generator tool which generates interface definitions and code that implement a query object can also generate a database schema access query object that retrieves the database schema. Instead of retrieving data from the database, the database schema access query object retrieves “metadata” concerning the database schema from the database. The metadata is then displayed as part of a graphic user interface which is used to construct the SQL query implemented by the query object.

[0019] The metadata retrieved by the database schema access object includes, but is not limited to, metadata which is defined for example, in the Java Database Connectivity (JDBC) 2.0 standard, including such data as the names of tables and stored procedures in the database and their descriptions, including column names and types for tables, input and output parameters for stored procedures and information about indexes, primary and foreign key relationships between tables.

[0020] In accordance with one embodiment of the invention, the database schema access object also verifies that an SQL query created by a user is valid by submitting the query to the database engine of the underlying database. This submission generates a result set and allows the database schema access object to display to the user a full description of the result set, including the types of resultant attributes as well as possible bounds on the cardinality of the result set.

[0021] In accordance with another embodiment of the invention the database schema access object contains methods which perform automatic mapping of “standard” SQL data types to vendor-specific data types so that the internal representation of the query object and most of the query generator tool internal code is not dependent on the underlying DBMS.

[0022] The above and further advantages of the invention may be better understood by referring to the following description in conjunction with the accompanying drawings in which:

[0023] FIG. 1 is a block schematic diagram of a client server system on which the present invention can be operated.

[0024] FIG. 2 is a block schematic diagram illustrating the interaction between client object, business objects and query objects in a three-tiered system.

[0025] FIG. 3 illustrates the internal organization of a database schema access object illustrating methods for browsing database schema, validating a query and translating data types.

[0026] FIG. 4 illustrates the generation of a query object and a database schema access object from information in the underlying database and query object library files.

[0027] FIG. 5 illustrates how code generated by a query object generator tool is used with a CORBA distributed object system.

[0028] FIG. 6 illustrates the internal architecture of an illustrative query object generator tool.

[0029] FIG. 7 is a flowchart illustrating a routine which retrieves database information.

[0030] FIG. 8 is a screen display illustrating the display of database schema information retrieved by the inventive database schema access object.

[0031] FIG. 9 is a flowchart illustrating the steps involved in validating an SQL query.

[0032] FIG. 10 is a flowchart illustrating the steps involved in translating data types.

[0033] FIG. 1 is a block diagram of a system 100 on which an illustrative query object generator tool constructed according to the present invention can run. As shown, the system 100 is a distributed computing environment comprising a plurality of individual computer nodes 102, 104, 106 and 108. The nodes are functionally organized into clients 102, 104 and 106 and at least one server 108 interconnected over a network 105. However, the clients 102, 104 and 106 and server 108 can also be implemented on a single node. Each node, whether a client 102, 104, 106 or server 108, is a conventionally programmed digital computer, respectively including a central processing unit (CPU) 118, 122, and a main memory 112, 124 interconnected with the CPU 118, 122. In addition, each client 102-106 and server 108 can include user interfacing devices, such as a monitor 114, keyboard 116 and mouse 117 and a storage device 112 (shown in FIG. 1 by way of example, for just one client 102). The server 108 includes a database 110, such as a relational database, file system or other, organized data storage system. The individual components implementing each node 102-108 are interconnected over a central system bus (not shown) used for exchanging address, data and control signals, although other forms of component interconnections are possible. Finally, the system 100 can include devices for accepting computer-readable storage mediums (not shown) and can be interconnected with the network 105 for exchanging data and control signals transmitted as a computer data signal in a carrier wave.

[0034] In the described embodiment, each node 102-108 is a network connectable computer, such as a Sun SparcStation™5 workstation running the Solaris™ operating system, a version of the UNIX® operating system, or an IBM-compatible computer running the Windows NT™ operating system. However, use of the systems and processes described and suggested herein are not limited to a particular computer configuration. SparcStation™ and Solaris™ are trademarks of Sun Microsystems, Inc., Mountain View, Calif. UNIX® is a registered trademark of The Open Group, Cambridge, Mass. Windows NT™ is a trademark of Microsoft Corporation, Redmond, Wash.

[0035] Distributed, computing environments can be logically viewed as a set of cooperating software components, referred to as “objects,” being executed on one or more computers interconnected by a network. The individual applications running on each computer can share a set of standard or application-specific objects and executing an application can cause it to interact with and use other software objects available locally and throughout the network. Each such object can, in turn, itself use other software objects. Thus, an application in a distributed computing environment can consist of the combination of application-specific objects and the combined local and remote objects it uses. When one object calls an operation on another object, the calling object is referred to as the “client” while the called object is referred to as the “server.” FIG. 2 is a block schematic diagram of a database client/server environment 200 using query objects 208 and 214 as might be implemented in the system 100 of FIG. 1. The environment 200 is functionally structured into three tiers. In the top tier 203, a client 102 (shown in FIG. 1) executes an application 202. The application 202 interacts, as indicated schematically by arrow 204, with business logic in the middle tier 205. The business logic is implemented as one or more business objects 206 (only one business object 206 is shown) and, in turn, interfaces with query objects 208 and 214. Both the business object 206 and the query objects 208 and 214 can be executed on either a client 102 or a server 108 (shown in FIG. 1). Other combinations and configurations of objects, including business object 206 or query object 208 and 214 are feasible.

[0036] In the bottom tier 207, a server 108 and an associated database 110 (shown in FIG. 1) include database management systems (DBMS systems) 218 and 222 (which may be executed on the server 108) along with associated databases 224 and 226, respectively. Query objects 208, 214 allow the business logic implemented in the business object 206 to access the DBMS systems 218, 222 without knowledge of the DBMS schema or query language.

[0037] More particularly, query objects 208, 214 are server objects that translate client requests into appropriate DBMS queries, issue those queries to the DBMS systems and return the results to the client. Functionally, each query object 208, 214 creates a logical “wrapper” that encapsulates a specific, application-dependent set of queries and provides the results to its clients as strongly typed values. Each query object 208, 214 is associated with a single DBMS system 218, 222, respectively, and has the capability of interacting with specific DBMS query APIs (represented by arrows 216 and 220) and parameters for the queries. However, the query object provides a DBMS-independent API (represented by arrows 210 and 212, respectively) to the business object 206 for accessing the databases 224, 226. Each query object also provides a mechanism for managing connections to the DBMS systems 218, 222 associated with the databases 224, 226, including methods for locating the databases 224, 226 in the distributed environment, methods for logging on to the DBMS systems 218, 222 and facilities for managing the connection resoures. A query object may also provide multi-threading support, if necessary.

[0038] Each query object may include several distinct queries. The query object code for each query is created by a query object generator tool in response to a query written by the query object developer in a standard language, such as SQL. In order to assist the developer in writing the SQL language queries, the query object generator tool utilizes the inventive database schema access object to retrieve and to display the schema of the underlying database to the developer. Since the database schema access object is closely tied to the underlying database, the database schema access object also serves as a repository of code to perform other database-related activities. These activities include, submitting a proposed query to the underlying database query engine in order to validate the query and performing data type translations between the SQL data types used in the developer-formulated queries and the vender-specific data types of the underlying database.

[0039] The general internal organization of a database schema access object is shown in FIG. 3. In particular, the database schema access object, 300, contains a plurality of methods, which are called by the query object generator tool. These methods fall into three distinct groups. The first group, 302, contains methods which are used to retrieve information from the underlying database, including table types, tables, procedures, table columns, procedure columns, catalogs, and database schema.

[0040] The second method group 304, contains methods which are used to validate an SQL language query entered by the query object developer. These latter methods include the parse_SQL_query( ) method, which is used to validate the SQL input query and determine its result set and input parameters. The ping( ) method is used to validate a connection to the underlying database and the Do_Query( ) method which is used to execute a query by means, of the underlying database query engine in order to perform DDL operations (such as creating and deleting tables), creating stored procedures, etc. The parse_SQL_query( ) method contains an automated rollback mechanism to prevent the query from actually being executed and changing the data since the query is being validated for later use in the query object.

[0041] The third group of methods, 306, includes methods which convert data types, column types and input parameters of the SQL input query to the data types, column types and input parameters of the vender-specific database.

[0042] The database schema access object can be hand coded by a developer or generated by an automated query object generator tool. FIG. 4 illustrates the operation of a generator tool which generates the components, of a query object and, optionally, the components of a database schema access object as illustrated in FIG. 3. In particular, the query object generator tool 400 utilizes information obtained from database 404 and query object libraries 406 to construct a query object 408. The query object generator tool 400 includes a mechanism (not shown) for obtaining the database schema from database 400 as indicated schematically by arrow 405. The database schema may be presented to a user by means of an optional GUI 402 to aid the user in formulating a query which is consistent with the database schema. When the query information has been obtained from the user, the query object generator tool 400 utilizes object-oriented class code found in the query object library 406 to instantiate code generator objects (not shown) as indicated schematically by arrow 407. The code generator objects then generate the source code for the query object 408 as indicated by arrow 410. The code generators may also generate build scripts (not shown) which allow the query object 408 to be built from the generated source code.

[0043] The code generators also use the information obtained from database 404 and libraries 406 to generate a test object 416 as indicated by arrow 414. The test object corresponds to the query object 408. A set of the query test objects 418 is also generated as indicated by arrow 412 and each of the query objects corresponds to one of the queries in the query object 408. Both the test object 416 and the query objects 418 are used with the inventive test framework to generate a test GUI which can display and run the queries in a query object as described below.

[0044] In the preferred embodiment, the client/server environment 200 is implemented in compliance with the Common Object Request Broker Architecture (CORBA), such as described in “The Common Object Request Broker: Architecture and Specification,” Rev. 2.0, Object Management Group, Inc. (July 1995), the disclosure of which is incorporated herein by reference. The application 202, business object 206 and query objects 208, 214 each export an API defined in Interface Definition Language (IDL) and interface with each other via an associated Object Request Broker (ORB) illustrated in FIG. 5. Each query object 208, 214 returns a set of IDL structures whose type is derived from the database schema at the time the query object 208, 214 is implemented and this interface is used by clients of the query object. In a similar manner the test object and each of the query test objects also export an IDL interface which insures that they will be compatible with the test framework.

[0045] FIG. 5 illustrates, in a very schematic form, the basic CORBA architecture which defines a peer-to-peer distributed computing facility where all applications are objects (in the sense of object orientation). In such a system, a client 500 communicates with the server 502 by means of an object request broker or ORB 512. an object, such as a database schema access object can be located on the server 502. The ORB 512 operates with a transport 514 that conveys information between the client 500 and server 502. The client 500 communicates with the ORB 512 by means of the aforementioned IDL interface and a reference to the query object or the test object. The database schema access object reference, in turn, contains an identification of the schema access object implementation 520 in the server 502 so that the server 502 can pass a request to the correct object implementation. The schema access object implementation 520 communicates with a database 504 to retrieve data and interact with the database engine to retrieve the database metadata and validate queries under control of the generator tool.

[0046] The entire CORBA architecture is actually implemented in a conventional programming language, such as C, C++, Smalltalk or the JAVA™ programming language. Implementations in a variety of languages are available from a number of vendors who typically provide a compiler, called an IDL compiler 522, bundled with their ORB products. The compiler 522 generates header files which define the OMG IDL interfaces and can be incorporated into application programs. The compilers also generate the client stub code 506 and the server skeleton code 508 for each interface.

[0047] The client 500, which may be the generator tool, can directly link to the OMG IDL stub code 506. As far as the client is concerned, an invocation of the stub code 506 appears to be a local function call. Once invoked, the stub code 506 provides an interface to the ORB 512 that encodes the operation's parameters into communication formats suitable for transmission on the transport 514 to the server 502. The stub code then transmits a request for service to the server 502.

[0048] At the server side, the OMG IDL skeleton code 508 is the corresponding implementation of the OMG IDL interface. When the ORB 512 receives a request, the skeleton code 508 decodes the request parameters and generates a call to the schema access object implementation 525 in the server 502. When the server completes processing of the request, the skeleton code 508 and stub code 506 return the results to the client 500. If an error has occurred, exception information generated by the server or by the ORB is returned. An object adapter 510 comprises the interface between the ORB 512, the skeleton code 508 and the server 520. Object adapters, such as adapter 510, support functions, such as registration of object implementations and activation of servers.

[0049] The query object generator tool generates a query object. Initially, the query object generator tool, needs a database schema access object to operate, but after a database schema access object has been obtained, the tool can generate other database schema access objects. The initial database schema access object may be obtained by means of a number of methods, such as hand coding. The query object generator tool preferably generates both a query object and a database schema access object for use with a conventional CORBA system such as that illustrated in FIG. 5. When operating with such a CORBA system, the query object generator tool 516 generates CORBA IDL interface code 518. This IDL code is applied to a conventional IDL compiler 522 which, in turn, generates the client stub code 506 and the server skeleton 508.

[0050] An example of generic IDL code generated by the query object generator tool 516 for a database schema access object is illustrated in the following code snippet:

[0051] The IDL code defines database structures and constants. The listed methods retrieve database objects, such as table types, tables, procedures and catalogs, and columns, such as table columns and procedure columns, and parse an SQL query.

[0052] In addition, the query object generator tool 516 generates source code for the server implementation of the database schema access object 525 in the program language used in the CORBA system. The CORBA IDL code 518 is written in standard IDL language. However, the CORBA server implementation 525 must be written in a language used on the server 502. This may, for example, be C++ or Java or some other language which is suitable for implementation on server 502. A code snippet illustrating implementation source code for a database schema access object named DBQueryImpl which implements the DBQuery interface described above appears as follows. This source code has been written in the JAVA™ programming language.

[0053] As shown, the implemented schema access object has methods for returning tables types (get_table_types( )), tables (get_tables( )), procedures (get_procedures( )), get_table_columns( )), procedure columns (get_procedure_columns( )), catalogs (get_catalogs( )), schemas (get_schemas( )). The parse_SQL_query( ) method parses the SQL query entered by the developer, connects to the database, executes the query obtains the result set, and rolls back the transaction to prevent a modification of the database. Its operation is described in more detail with respect to FIG. 9 below. The do_query( ) method actually performs the query. Finally, the convertDataType( ), convertColumType( ) and setInputparameter( ) methods perform data conversion.

[0054] The internal architecture of the query object generator tool which can be used to generate a database schema access object and which interacts with the object is illustrated in block schematic diagram form in FIG. 6. The query object generator tool 600 comprises a query object internal state object 602, code generator object 604 and a builder object 606. The query object internal state object 602 allows the user to save a logical definition of a query object in an intermediate file, such as file 612. In particular, object 602 can store and retrieve file information in file 612 as indicated schematically by arrow 614. The information saved in file 612 is not the entire query object but is sufficient amount of information to be able to reconstruct the query object. This allows the user to open an existing query object for modification without having to restart from the beginning.

[0055] The query object internal state object 602 is actually a collection of objects which model input parameters, result structures and various implementation options. The query object generator tool 600 may optionally include a graphic user interface 634 which enables a user, at terminal 636, to operate interactively with the generator tool 600.

[0056] Generator tool 600 also receives information from the database 622 in order to allow the user to formulate the query and test the query. Extracting information from, the database 622 can be performed in several manners. Preferably, generator tool 600 uses the inventive database schema access object 618 to retrieve the schema of the underlying database 622 as indicated schematically by arrow 620. The schema information is returned to generator tool 600 as indicated by arrow 616 and may be presented graphically to the user by means of the GUI 634 on terminal 636. The schema information assists the user in formulating a query.

[0057] The generator 600 also receives input information from the configuration file 608 and include files 610. The tool 600 reads the configuration files 608 when it starts up. These files tell the tool 600 about the environment in which it is running and they include such information as the JDBC drivers that are available and the location of various software programs. The configuration files also contain the name of the include directory 610 which contains various “boilerplate” files. When the tool 600 starts up, it first tries to read the configuration file in a directory that is “hard coded” into the tool. If the configuration file is not found, the tool then looks for a configuration file in the user's home directory. If the file is still not found, the tool looks in the current directory.

[0058] Generator tool 600 may further receive query strings and parameter information from the user, via terminal 636. After the input information has been received, the query object generator tool 600 utilizes an appropriately selected code generator 604 to generate the source code which implements the query object. In particular, the code generator 604 generates the query object server implementation 624 and the query object IDL code 625 and, as mentioned above, may optionally generate a database schema access server implementation and IDL code. The code generator object which is actually used to generate specific query object source code must generate code which is compatible with the underlying database and is also written in the implementation language which is used to implement the CORBA server. Accordingly, the code generator classes are arranged in a class hierarchy with subclasses that depend on the implementation language and the underlying DBMS language.

[0059] In addition, the tool 600 may also generate build and package scripts 626 which can be used to build the objects from the source code 624 and the IDL code 625. The source code and the build scripts are provided to a builder object 606 which generates the final query object package 632 that can be installed on a CORBA server. As previously described, the query object IDL interface code 625 is provided to a conventional IDL compiler to generate the client stub code and server skeleton code.

[0060] The database schema access object can be used retrieve information from the underlying database to perform a browsing function. One way to use the schema access object is in a browsing routine which uses the object to retrieve the database details and display the details on a graphic screen display. Illustrative source code for an object which performs a browsing function is shown in the code snippet below which implements a browsing object named DBSchema:

[0061] The browsing routine implemented by this object is shown in FIG. 7. The routine begins in step 700 and proceeds to step 702 where the CORBA ORB is created and initialized. Next, in step 704, the ORB naming services are used to locate the DBQuery database schema access object. In step 706, the routine logs onto the appropriate database. The login routine involves establishing a new connection to the DBQuery object and using the Ping( ) method in the object to check the database connection.

[0062] Next, in steps 708, 710 and 712, the routine obtains the database objects, the database procedures and the database and procedure columns, respetively. The database objects are obtained by calling the get_tables( ) method in the DBQuery object and returning the resulting names to a text column. The database procedures are retrieved by calling the get_procedures( ) method in the DBQuery object and the columns are retrieved by calling the get_table_columns( ) and get_procedure_columns( ) methods in the DBQuery object. The routine then ends in step 714.

[0063] The resulting data can be displayed in graphic format as shown in FIG. 8. The query object generator tool is much like any other editing program which allows a user to define and examine one or more query objects, change their definitions and manipulate them in various ways. The query objects are selected by using a graphic user interface which has a menu of operations and shows the state of the current query object being defined. The menu options might include such options as “New” which would allow a new query object to be created. Another menu options might be “Open” which would allow an existing query object to be restored from an intermediate file. a “Save” option would allow the query object contents to be stored in the intermediate file.

[0064] Each query object contains one or more queries which are also displayed on the graphic display. The queries can be manipulated by other menu options. These options might include such operations as “Add Query”, “Delete Query” and “Modify Query”.

[0065] Selection of the “Add Query” option brings up the screen shown in FIG. 8. The Add Query screen 800 contains a text field 802 Which allows entry of a query name and a text field 804 which allows entry of the SQL query text.

[0066] The database schema area 808 displays details of the database schema which have been previously retrieved by means of a database schema access query object or in another manner as previously described. The display consists of a scrolling list 816 of tables, views and stored procedures. When one of these database “objects” is selected, its schema description, including column names 818 and data types 820 can be displayed. The schema display assists a user in correctly constructing the query string in text box 804.

[0067] After the SQL query string has been constructed in text box 804, the user can press the, “Apply” command button 810 which saves the query. The user can use the “Cancel” button 812 to cancel the add query object operation or the “Clear” button 814 which clears the contents of the text fields 802 and 804.

[0068] FIG. 9 illustrates a routine by which a query entered by the user is checked and validated using a method in the inventive database schema access object using a method, such as the parse_SQL_query( ) method described above. This routine starts in step 900 and proceeds to step 902 where a connection is created to the underlying database. This connection can be set up using a conventional method. For example, In the case of a JDBC compliant database, the connection can be created by instantiating a connection object.

[0069] Next, in step 904, if the database utilizes an “auto commit” feature, this is disabled to prevent the query from actually modifying data in the database. Such modification would not be appropriate, since the purpose of the method is to validate the query for later use, rather than to apply it against a valid database while the tool is in use. At this point the query entered by the user (for example, an SQL query) would be prepared for execution by, for example, calling the prepareCall( ) method in the aforementioned connection object. However, the query must still be, executed to insure that it is parsed by the DBMS engine for correctness, since some DBMS drivers do not parse the query in the prepare phase. Accordingly, in step 906, parameters for the query are set and, in step 908, the query is executed.

[0070] As previously mentioned, in order to prevent the query from modifying data, in step 910, a rollback operation is automatically executed and, in step 912, the auto commit function, if available, is re-enabled.

[0071] Next, in step 914, the results are obtained from the query which results are displayed on a display screen illustrated in FIG. 8. In step 916, the connection to the database is released and the routine ends in step 918.

[0072] FIG. 10 illustrates the operation of routine in which SQL data types are replaced by the underlying DBMS data types using a method such as the convertDataType( ) method described above. In particular, the routine starts in step 1000 and proceeds to step 1002 in Which the SQL data type is received from a parsing routine which parses the user-entered SQL query. Next, in step 1004, the corresponding DBMS data type is retrieved using a lookup mechanism such as a lookup table. In step 1006, the corresponding DBMS data type is returned and the routine ends in step 1008.

[0073] A software implementation of the above-described embodiment may comprise a series of computer instructions either fixed on a tangible medium, such as a computer readable media, e.g. a diskette, a CD-ROM, a ROM memory, or a fixed disk, or transmissible to a computer system, via a modem or other interface device over a medium. The medium can be either a tangible medium, including, but not limited to, optical or analog communications lines, or may be implemented with wireless techniques, including but not limited to microwave, infrared or other transmission techniques. It may also be the Internet. The series of computer instructions embodies all or part of the functionality previously described herein with respect to the invention Those skilled in the art will appreciate that such computer instructions can be written in a number of programming languages for use with many computer architectures or operating systems. Further, such instructions may be stored using any memory technology, present or future, including, but not limited to, semiconductor, magnetic, optical or other memory devices, or transmitted using any communications technology, present or future, including but not limited to optical, infrared, microwave, or other transmission technologies. It is contemplated that such a computer program product maybe distributed as a removable media with accompanying printed or electronic documentation, e.g., shrink wrapped software, pre-loaded with a computer system, e.g., on system ROM or fixed disk, or distributed from a server or electronic bulletin board over a network, e.g., the Interment or World Wide Web.

[0074] Although an exemplary embodiment of the invention has been disclosed, it will be apparent to those skilled in the art that various changes and modifications can be made which will achieve some of the advantages of the invention without departing from the spirit and scope of the invention. For example, it will be obvious to those reasonably skilled in the art that, although the description was directed to a particular hardware system and operating system, other hardware and operating system software could be used in the same manner as that described. Other aspects, such as the specific instructions utilized to achieve a particular function, as well as other modifications to the, inventive concept are intended to be covered by the appended claims.