DBUtility Overview.

DBUtility is a Java application that:

Allows the display and execution of stored procedures.
Provides scripting to execute one or more stored procedures.
Provides scripting to execute a series of stored procedures scripts simultaneously for stress testing.
Allows the comparison of the results of matched stored procedures or SQL across the same (test to prod) or different (DB2 vs MySQL) relational databases
Provides scripting to transfer data from one system to another (prod to test or Oracle to DB2)
Run one or more sets of SQL statements (select, insert, delete) against a relational database

System Prerequisites

DBUtility is written to Java 1.6 and it requires that version (at a minimum) of the JRE.

DBUtility does not provide the database connection software. That must be provided and installed by the user. In addition the jar or zip files needed by the database for JDBC connections must be downloaded also (If not provided as part of the database install). The data jar file that allows connections to the database must be included in the classpath of the DBUtility app. The list of databases and jar files are below

Database		JDBC zip or jar
DB2 DB2 Connect or Express Edition		db2java.zip Look in C:\IBM\SQLLIB\java or C:\Program Files\:\IBM\SQLLIB\java
MySQL		mysql-connector-java-5.1.13-bin.jar Downloaded from http://dev.mysql.com/downloads/connector/j/
Oracle Express Edition		ojdbc14.zip Downloaded from http://www.oracle.com/technetwork/database/features/jdbc/index-091264.html

System Limitations

Support for BLOB’s, CLOB’s and comparison of long varchars is either not implemented and/or limited.

Program Installation

Unzip the DBUtiliyt.zip file into a new directory (e.g. DBUtility). The following files should be present.

File	Description
DBUtility.jar	DBUtility Java application of course
run.bat	Example Windows startup file to execute DBUtility. Modify classpath as needed to include needed database JDBC zip or jar files.
startup.xml	User startup and script window configuration file
db.xml	Lists databases and connection information. The file is configured to include DB2 (Express Edition) SAMPLE, world, and world2 databases Oracle (Express Edition) – world database MySQL (Community version) – world and world2 databases The various world and world2 databases can be defined using the scripts obtained from the DBUtility web page. The DB2 SAMPLE database is a database that can be created by the ‘First Steps’ panel provided by the Express Edition. The world and world2 databases are based that provided by MySQL, and modified to run under DB2 and Oracle. There may be some differences (intentional or otherwise) in how they are defined on the different database types and/or with the data loaded by the world/world2 scripts.
keywords.xml	Lists keywords used by the various DBUtility options and some help text
xercesImpl.jar jdom.jar	Used for reading, parsing and writing XML
jakarta-poi.jar jakarta-oro-2.0.8.jar	Used for writing SQL query results to Excel
commons-net-2.0.jar commons-net-ftp-2.0.jar	Used for FTP of scripts
mysql-connector-java-5.1.13-bin.jar	JDBC connector for MySQL
ojdbc14.zip	JDBC connector for Oracle

The application can be run from a network directory or copy all contents to your local drive (recommended) and run it from there.

If you are running in Windows, use the run.bat file to start the application. (If on Unix create a similar script file to start the application). The run.bat is configured to load DB2, Oracle and MySQL JBDC drivers.

After starting the application go to Utilities/Database Configurations. The first tab ‘Drivers/Connection Strings’ has entries for DB2, MySQL, and Oracle (Express Edition). The ‘DBType/Name’ tab shows database names configured for each database type. The names shown are assuming the various sample scripts have been run (e.g., create a ‘world’ database on DB2 similar to the example MySQL world database). Add, delete or update the entries as needed.

The information displayed on the Database Configuration tables is stored in db.xml.

DBUtility Options

The various input or script windows are displayed via the DBUtilites menu drop.

Database Connections

The first time any script or stored procedure is executed there will be a delay in execution as a connection(s) is established. The connections are maintained for a few minutes after the script executes so subsequent executions run faster. The connections may drop however if there is an appreciable lag between running scripts. If you execute a script and it doesn’t run properly try clicking on Utilities/Reset All DB Connections on the menu. This actually closes all connections so the application will reopen connections from scratch.

If you have to run a large number of scripts together(see below) you may also want to use the menu option to close the connections when done to free them up for other users (future enhancement – provide a keyword to do this)

Use of Symbolics

Symbolics start with a ‘&’ and can be used anywhere in SQL or stored procedures. If the replacement value of the symbolic contains specials characters, e.g. a ‘$’ symbol preface the special character with a ‘\’ (backslash). Consult java.util.regex.Pattern for the list of special characters.

Exectuting Stored Procedures

There are 2 ways of executing stored procedures, prompted and via a script. The following covers the prompted. The scripted method is next.

From main menu bar click on Utilities/List Stored Procedures
Select the DBType (names from db.xml) for listing the available databases of that type.
Select the system that you want to get a list of stored procedures from.
Type in a new schema and/or stored procedure prefix (defaults that are in startup.xml). A wildcard ‘%’ character will be appended to the end under the covers.
Select a stored procedure from the list of stored procedure names based on the criteria specified above.
Once a stored procedure is selected, enter the appropriate input parameters on the displayed input panel.
Some simple validation occurs when parameter values are entered, based on the parameter data type. (e.g. an integer parameter requires all numbers)
Click Execute to run the stored procedure and list results in the output text area.
Create a BatchSPRunner script (see next section) by clicking Options/Create Batch Script

BatchSPRunner General Overview

BatchSPRunner provides options to:

Load and save test scripts that contain 1 or more stored procedures with parameters to be executed
Execute a script containing one or more stored procedures and display the results
Execute a file containing a list of test script files. Each script file runs as a separate thread so volume testing can be conducted.

Select BatchSPRunner from the DBUtilities menu. A text area is on the left/top where the script is entered and the results are displayed in the right/bottom window. Multiple BatchSPRunner script windows can be opened and executed at the same time.

The menu bar is modified to include the regular edit functions. The Keyword menu provides a list of valid keywords for creating a batch script. Leaving the mouse over a keyword will display a short explanation on the use of the keyword.

With regards to the check boxes, the ‘Display Batch Output’ will display the execute results of the script in the lower/right window if checked. This is most useful when doing interactive testing and debugging of the script.

The ‘Input is File List’ check box indicates that the upper window contains a script containing a list of files to be executed, rather than the script itself. In general if you are executing a list of files, do not check the ‘Display Batch Output’. It is not a problem if it is checked but the results window will contain a mix of output from each individual script file being executed and may not be very useful.

By default script files are held in the BatchSPFiles subdirectory relative to whatever directory the application runs from. Script files can be loaded, modified and saved within the application.

In general, a script is made up of key words and (usually) one or more values. Keywords are separated by their values by an ‘=’ sign and the end of the values must end with a ‘;’. If a keyword allows multiple values, the values are comma separated. Keyword values can run over multiple lines. There is no continuation character. End the ‘line’ with a ‘;’.

Lines starting with ‘--‘ are comments and are ignored.

The key words (case insensitive) and values are:

Keyword	Description
&symbolic	Create a symbolic and assign a value. The value will be substituted when the symbolic is found in the script. Currently symbolic substitution is done on LogFile, SPName, and Parameters values; &emplid=123456789; &owner=TEST; -- SPNAME=&owner.GET_EMPLID_DETAILS;
ClearAfter	Clear output area after n sp's execute, or -1 (default) to not clear (help prevent out of memory condition) ClearAfter=10; -- Clear the output area after 10 stored procedure calls have executed
System	System the script is to execute in System=MySQL;
ListOutputParameter	Used to display output and input/output parameter value(s) after the execution of a stored procedure. Separate multiple parameter names by a ‘,’. Reset the list to empty by specifying an empty list. Print all output parameters by specifying “all” (case insensitive) ListOutputParameter=ERROR_TEXT,TOTAL_AMT; ListOutputParameter=; reset list to empty ListOutputParameter=all; print all output and input/output parameters.
Logfile	File name where results should be logged relative to where the program executes Logfile = BatchSPFiles\substitutiontext.log.txt;
Parms	Parameters to be passed to the stored procedure. The parameter values are for the input or input/output parameters only. The parameters can be entered two ways. 1. List the parameters. In this form, the parameter list is comma separated. Use double quotes around a parameter if it contains a comma or quote. If you like you can also surround parameters that are spaces with double quotes. Parms = . 2011-01-30,"'774-437-8162'"," " Or symbolics can be used &date = 2011-01-30; &telephone='74-437-8162; &comments=; Parms=&date, &telephone,&comments; 2. List a file containing the parameters to be executed. Parameters of this type must start with a ‘\’ . Do not mistake it for an initial directory path command. Parms=\BatchSPFiles\EmplidParameters.txt; Parameters within this file do not start with ‘Parameters=’. Simply list the values ending each line with a ‘;’ and starting the next set of parameters on a new line. Currently symbolic replacement within a parameter file is not done. A parameter value identified by ‘\last\parameter name’ will take the parameter value for that parameter name from the previously executed stored procedure and substitute it in. Parms=2001-11-30,"'6178151086086'".\last\comment ; A parameter identified by ‘\sp name\parameter name’ will take the previously executed parameter value for the parameter name of the last execution of that named stored procedure and substitute it in. Parms=\OWNER.GET_EMPLID\HIRE_DATE, '6178151086086'".\last\comment;
Password	Password used to sign on to the system. You will be prompted if not provided. Password=mypassword;
Quit	Stop execution of the batch file. This is sometimes useful to insert in the middle of a script if you just want to execute the first part for some testing. Quit;
ReadCursor	Set to true if returned result set (if any) should be read or false if not. Default value is true. ReadCursor=true;
Schema	The owner of stored procedure. Schema=dbuser;
SPElapsedTime	Name of input/output or output parameter that holds a DB2 time duration representing the SP elapsed execution time. Used to report total and avg SP execution time at the end of the execution of the script. (Your SP should get a timestamp immediately on startup and then calculate a duration just before exiting) SPElapsedTime=SP_DURATION;
SPName	Name of the SP parameter to execute, e.g. SPName=list_cities;
StopIf	Stop if the output parameter is <, <=, =, >=, > or <> to the stop condition StopIf=RETURN_CODE>0;
System	Database system the script is to execute against. For MySQL it is the database name (e.g. world) System=TEST;
Userid	Userid to be used to sign on to the system. You will be prompted for signon if not provided. Userid=myuserid;
Validate	Set to true if the script is to just check parameter value assignment and not execute the SPs. The default value is false (execute the SPs). Validate=true;

Creating BatchSPRunner Test Data

Here’s a handy way to create test parameters if the SP’s are mainly retrieval SPs. Of course the same applies to updates if the data is entered initially from unit testing and the parameters are generated prior to re-initializing the database.

The method is to create a SQL query to format a parameter string with the necessary values. An example below creates a mix of parameter values, some fixed and some dependent on the underlying database records.

SELECT DISTINCT

'" ",1,0,0,' || CHAR(BILL_DATE,ISO) || ',' || ACCOUNT || ',M, , , ,1, 10;'

FROM

OWNER.TABLE

WHERE

BILL_DATE = '2010-10-31'

ORDER BY 1

Save the results in a text file and use the parameter file name option of the ‘Parms’ keyword.

StressTester

StressTester provides a way to execute multiple BatchSPRunner scripts simultaneously to provide a method to do stress testing. To use StressTester create one or more BatchSPRunner scripts. Then create a StressTester script to execute the BatchSPRunner scripts. A ‘dashboard’ provides information as to the status of the executing BatchSPRunner scripts. StressTester provides text replacement capabilities so that a template BatchSPRunner script can be used as a base for running a series of similar stored procedure executions.

The general process to use StressTester is:

Create one or more BatchSPRunner scripts.
Create a StressTester script that will load each BatchSPRunner script and replace any values as needed.
Click the ‘CreateTesters’ button at the bottom of the top/left StressTester script window. That will execute the StressTester script to create and load the individual BatchSPRunner scripts.
Assuming the StessTester script ran successfully (see results in lower/right ‘Load Status’ tab), click on the ‘Execute Status’ tab. A list of the BatchSPRunner scripts should be displayed.
The individual BatchSPRunner script windows can be maximized or minimized by clicking the corresponding buttons.
Click on the Execute button at the bottom of the top/left StressTester script window to start the scripts executing.
The status of the script executions will display in the ‘Execute Status’ tab.
A script can be cancelled while executing by clicking the button under the ‘Cancel Tester’ column for that script.

The key words (case insensitive) and values are:

Keyword	Description
Delimiter	Used to separate text values in the Replace keyword. (See Replace for its use.) Delimiter=\|\|;
Loadscript	Create a BatchSPRunner and load it with the given batch script. Loadscript=C:\DBUtility\BatchSPFiles\PurchaseTransaction.txt;
Replace	Replace the value before the delimiter that is found in the BatchSPRunner script with the value after the delimiter. Replace=db2test\|\|db2qa; In the example Replace statement above, ‘db2aq’ replaces ‘db2test’ wherever it is found in the BatchSPRunner script loaded via the prior Loadscript command.
Name	Names the BatchSPRunner script loaded via the Loadscript command. It is used to help identify the individual BatchSPRunner scripts being executed. Name=PurchaseTransaction1;
Password	StressTester will insert this password into the top of the loaded BatchSPRunner script so the script can sign on to the database with prompting the user. This keyword should come before the Loadscript keyword so that the password will be added to each BatchSPRunner script subsequently loaded via Loadscript. Password=mypassword;
Quit	Stop execution of the StressTester script. This is sometimes useful to insert in the middle of a script if you just want to execute the first part of the script for some testing. Quit;
Userid	StressTester will insert this user id into the top of the BatchSPRunner script loaded by Loadscript so the script can sign on to the database without prompting the user. This keyword should come before the Loadscript keyword so that the userid will be added to each BatchSPRunner script subsequently loaded via Loadscript. Userid=myuserid;

DBCompare

DBCompare allows the execution of matched sets of SQL or stored procedures against the same or different databases. Some examples of exercising this option are comparing:

Data between systems to ensure identical values across systems.
System tables to ensure identical setup across systems.
Regression testing between existing and modified stored procedures to ensure existing functionality is unimpaired.
Comparing table records between test and prod after running batch programs or stored procedures to check for differences, ie. to ensure that program changes only affected data that should be different.

The DBCompare script window is similar to BatchSPRunner.

A comparison script is made up of either 2 SQL statements, or 2 stored procedures. The 2 statements or procedures are executed and the output parameters (for stored procedures) and/or result sets are compared. Only the differences in output parameters and/or result sets are shown.

By default, DBCompare files are held in the DBCompare subdirectory relative to whatever directory DBUtility runs from. Comparison files can be loaded, modified and saved within DBUtility. The files are run interactively with the deltas displayed in the right/lower results window.

A comparison file is made up of key words and values in the same manner as a BatchSPRunner script. The comparison executes when either the last line of the script in the input window is read and no execution has yet occurred OR the ‘Execute’ keyword is hit - so multiple comparisons can be done in one script. Currently there is no option to read and execute scripts from a separate file like BatchSPRunner

The SQL or SP called in each environment must of course have the same number of columns returned and in the same sort order.

The key words (case insensitive) and values are:

Keyword	Description
&symbolic	A symbolic variable. Is case sensitive. &emplid=123456789;
&OWNER	This symbolic is not assigned a value. It is used in the SQL/SP statement. The symbolic is replaced by &OWNER1 and &OWNER2 symbolics.
&OWNER1	The owner of the 1^st SQL or SP to be used in comparison. Is case sensitive &OWNER1=TEST;
&OWNER2	The owner of the 2^st SQL or SP to be used in comparison. Is case sensitive &OWNER2=PROD;
ContinueOnDBError	Useful when running a series of SQL or SP comparisons. If set to true then and error in one comparison will not stop the script. The default is false – so any errors will stop script execution ContinueOnDBError=true;
CompareOutputParameters	List the output or input/output parameters to be compared between 2 stored procedures. Multiple parameters are comma separated. Use a value of ‘all’ to compare all parameters returned in the stored procedure. CompareOutputParameters=emp_address1,emp_emp_address2;
DbType1	Only needed if system value is non-unique value in db.xml. (ie. If you have a ‘world’ system in both DB2 and MySQL) DbType1=DB2;
DbType2	Only needed if system value is non-unique value in db.xml. DbType2=DB2;
Execute	Execute the comparison. Use if the SP does not have any parameters or if there are multiple SP or SQL comparisons in the script. Also use if you want to execute the same SP’s with different parameters. SP1=X; SP2= Y; Execute; SP1=A; Parms1=1,2,3; SP2=B; Parms2=4,5,6; Execute; Parms1=7,8,9; Parms2=10,11,12; Execute;
File	Process a file containing the store procedure or SQL comparison script. The file can contain symbolics.
IgnoreColumns	Ignore the column(s) in the comparison. Multiple column names are comma separated. Ingnore=LastUpdate;
IgnoreSys1Rows	Ignore rows from System1 not found on System2. Valid values: true or false(default). IgnoreSys1Rows=true;
IgnoreSys2Rows	Ignore rows from System2 not found on System1. Valid values: true or false(default). IgnoreSys1Rows=true;
KeyColumns	Column names or numbers to be used as the key columns to compare the 2 SQL result sets. Differences in all other column values in the result sets will be output below the key column(s) . (Assuming SummaryKeyColumns key word not used.) KeyColumns=Employee_Name, Employee_Dept;
MaximumDeltas	Maximum number of differences allowed before program stops MaximumDeltas=20;
MaxRows	Stop the comparison after reading this many rows in a result set. MaxRows=100;
NumberKeyColumns	This is obsolete. Use KeyColumns keyword. First n (key) columns of SQL to be compared between systems NumberKeyColumns=4;
Parms	Use the parameter values listed for both stored procedures. This will overlay previously Parm1 and Parn values; Parms=123456789,10/19/2006;
Parms1	Parameter list for SP1 Parms1=123456789,10/19/2006;
Parms2	Parameter list for SP2 Parms2=123456789,10/19/2006;
Print1Input	Will only print the first SQL (SQL1) in the output. This can be helpful to reduce the size of the report when running a large number of comparisons. The default is to print both. Print1Input=true;
Quit;	Stop execution of the script.
ResetDeltaCounter	Set to true if you want to reset the delta counter after each comparison. The default is false – so once the number of deltas equals the MaximumDeltas value the script will stop. ResetDeltaCounter=true;
SP	Stored procedure to execute on both systems. (Each system has the same stored procedure name) SP=GetEmployeeHistory
SP1	Name of stored procedure to be executed on system 1. SP1=GetEmployeeHistory;
SP2	Name of stored procedure to be executed on system 2 SP2=GetEmployeeHist;
SQL	SQL to execute on both systems SQL= SELECT NAME, PRECOMPDATE, PRECOMPTIME, PDSNAME from sysibm.SYSDBRM where plcreator = &OWNER and plname like DBUSER%’
SQL1	The SQL to be executed on system 1. SQL1=valid SQL string;
SQL2	The SQL to be executed on system 2. SQL2=valid SQL string;
SummaryKeyColumns	Comma separated list of summary column(s) that any differences will be reported at when comparing 2 SQL result sets. Only the values for the summary key columns will be output. Non key column differences will not be output. SummaryKeyColumns=EmployeeID;
System1	System to execute first SQL or SP on. Consider this system as having the new version or results. For backward compatibility, the Sys1 keyword can still be used. System1=TEST;
System2	System to execute 2^nd SQL or SP on. Consider this system as having the old version or results. For backward compatibility, the Sys2 keyword can still be used. System2=PROD;

DBTransfer

DBTransfer allows a select SQL statement to be run on one database/system with the result set data either being used to insert new rows or update existing rows on another database/system.

Insert, update, delete statements always execute against the destination database. Selects always execute against the source database.

The key words (case insensitive) and values are:

Keyword	Description
&symbolic	A symbolic variable that gets substituted into any of the SQL. Is case sensitive. &where= where emplid=123456789 and work_date = ‘10/22/2006’;
AutoCommit	If set to false (the default value), you will be promoted to confirm the commit of any insert, update, or delete statement. Setting to true will cause commits to be done as needed without asked for confirmation. Autocommit=true;
CommitEvery	Will commit every n records inserted or updated as specified. A value of -1 (the default) will cause a commit only at the end of the read/insert cycle. If AutoCommit is set to false a confirmation box will be displayed and you will need to confirm the commit each time the count is hit. CommitEvery=200;
Delete ….	Delete SQL to execute. Always runs against the Destination database. Delete from dbt2test.employees &where;
Destination	Database that the insert statement will execute in Destination=DB2TEST;
DestinationDBType	The type of destination database to connect to. Only needed if the ‘destination’ name is non-unique among the listed database types in db.xml. DestinationDBType=DB2;
DisplayStatusEvery;	Displays a message for every n records inserted or updated. (Just a means to visually see that the process is running). The default is 200. DisplayStatusEvery=50;
Execute	Execute the previously defined delete or select and insert/update SQL. Execute;
ExecuteBatchAt	If the database supports batch inserts/updates, execute the batch command after this many SQL statements execute. ExecuteBatchAt=200;
Insert …	Insert SQL to execute. The insert statement executes against the destination database. The columns and attributes must match 1 for 1 against the columns in the select SQL result set. Insert into db2test.employees (emplid, emplname) values (?,?);
Quit;	Stop execute of the transfer script at this point; Quit;
Select …	Select sql to execute. The select statement executes against the source database. The columns and attributes must match those in the insert. Select emplid, emplname from db2prod.employees &where;
Source	Specifies the source database that the select statement will execute against. Source=DB2PROD;
SourceDBType	The type of source database to connect to. Only needed if the ‘destination’ name is non-unique among the listed database types in db.xml. SourceDBType=DB2;
Update …	Update SQL to execute. The update executes against the destination database. An update statement can be run on its own, or executed in tandem with a select statement. If an update is run with a select, symbolics are used in the update statement to match to the data to be used from the select statement. The symbolic name must match the column name from the select statement. Update run without select: Update test.employees set work_date = ‘10/23/2006’ &where; Execute; Update matched to select: Select emplid, yearly_salary, vacation_days from db2prod.employees; Update db2test.employees Set yearly_salary = &yearly_salary, Vacation_days = &vacation_days Where emplid = &emplid; Execute;
UseBatch	Batch the insert/update operations. Check to see if your database supports batch operation as if not, it may cause the JVM to crash. Batching the insert or update operations can reduce execution time. Used with ExecuteBatchAt keyword. Default is false. UseBatch=true;

DBQuery

DBQuery allows the execution of select, insert, update and/or delete SQL.

Select the database and system from the drop down lists (The values are based on entries in db.xml)

Type your SQL in the left/upper text input window. If multiple SQL statements are listed end each with a ‘;’. When the ‘Execute’ button is pressed, each SQL will be executed in turn.

Results are displayed in the right/lower window.

The CompareWizard and TransferWizard are available from either Options menu dropdown, or right clicking the mouse when in the script window. See the descriptions of the wizards further down in this document.

Note that a delete SQL statement without any where phrase (to delete all rows in a table) may display 0 as the number of rows to be deleted in the confirmation dialog box (assuming Autocommit=false) rather than the actual number of rows deleted – which can of course be misleading. This is due to the way the database processes the delete statement.

Keyword	Description
&symbolic	A symbolic variable that gets substituted into any of the SQL. Is case sensitive. &where= where emplid=123456789 and work_date = ‘10/22/2006’;
AutoCommit	If set to false (the default value), you will be promoted to confirm the commit of any insert, update, or delete statement. Setting to true will cause commits to be done as needed without asked for confirmation. Autocommit=true;
BypassDisplay	Don’t display the results of the select statement. The default is false. Useful if you just want the results to be writted to Excel or a CSV file. BypassDisplay=true;
DbType	Override the dropdown DbType value. Use this if you want to run a subsequent query on another database. Reset value to spaces to again use the dropdown value. DbType=MySQL;
Delete …	Delete SQL to execute. Delete from owner.employees &where;
Insert ….	Insert SQL to execute. The columns and attributes must match those in the select SQL result set. Insert into testowner.employees (emplid, emplname) values (‘123456789’,’Doe, John’);
MaxRows	Stop reading when more than this number of rows are in a result set. MaxRows=100;
OutputExcel	Output the results of a select to an Excel file. Unless BypassDisplay=true, the result set is still displayed in the output window. Note that Excel has a limit of 64K rows. OutputExcel=c:\sqlresults.xls;
OutputCSV	Output the results of a select to an CSV file. . Unless BypassDisplay=true, the result set is still displayed in the output window. OutputCSV=c:\sqlresults.csv;
Quit	Stop execution of the transfer script. Useful if you only want to execute the first part of script. Quit;
Select ….	Select sql to execute. Select emplid, emplname from owner.employees &where;
System	Override the dropdown system value. Use this if you want to run a subsequent query on another database system. Reset value to spaces to again use the dropdown value. System=world;
Update ….	Update SQL to execute. Update testowern.employees set work_date = ‘10/23/2006’ &where;

DBCompareWizard

The CompareWizard is available from the DBQuery Options menu dropdown. The premise is that a select statement has been developed and tested in DBQuery. Clicking on the CompareWizard option will use the query as the start of creating a DBCompare script. Create or cut/paste in corresponding sql for the ‘System2’ sql. As you work through the wizard the DBCompare script will be displayed in the lower/right window. When you are done a DBCompare window will be opened and the script placed in it for execution.

DBTransferWizard

The TransferWizard is available from the DBQuery Options menu dropdown. The premise is that a select statement has been developed and tested in DBQuery. Clicking on the TransferWizard option will use the query as the start of creating a DBTransfer script. As you work through the wizard the DBTransfer script will be displayed in the lower/right window. When you are done a DBTransfer window will be opened and the script placed in it for execution.

Future Enhancements

More user configurable options
Add connection parameters for database connection to db.xml.
Improve keyword help display and prompting.
Add online help manual
Add email link on Help menu
Full support for BLOB’s, CLOB’s, etc.
More database exploratory tools

Bug Reports and Enhancement Requests

Please send all bug reports and/or suggestions for enhancements to Eric Foertsch (efoertsch@fisincorporated.com)