The name of the connection profile to use as the source connection. If -sourceprofile is not specified, the current connection is used as the source.

If the profile name contains spaces or dashes, it has to be quoted.

This parameter supports auto-completion

If the name of your source profile is not unique across all profiles, you will need to specify the group in which the profile is located with this parameter.

If the group name contains spaces or dashes, it has to be quoted.

Allows to specify a full connection definition as a single parameter (and thus does not require a pre-defined connection profile).

The connection is specified with a comma separated list of key value pairs:

e.g.: "username=foo,password=bar,url=jdbc:postgresql://localhost/mydb"

For a sample connection string please see the documentation for WbConnect.

If this parmeter is specified, -sourceProfile is ignored

The name of the connection profile to use as the target connection. If -targetProfile is not specified, the current connection is used as the target.

If the profile name contains spaces or dashes, it has to be quoted.

This parameter supports auto-completion

If the name of your target profile is not unique across all profiles, you will need to specify the group in which the profile is located with this parameter.

If the group name contains spaces or dashes, it has to be quoted.

Allows to specify a full connection definition as a single parameter (and thus does not require a pre-defined connection profile).

The connection is specified with a comma separated list of key value pairs:

e.g.: "username=foo,password=bar,url=jdbc:postgresql://localhost/mydb"

If this parmeter is specified, -sourceProfile is ignored

Possible values: true, false

If this parameter is set to true, all rows are deleted from the target table using a DELETE statement before copying the data.

Possible values: true, false

If this parameter is set to true, all rows are remove from the target table using a TRUNCATE statement before copying the data.

Not all DBMS support the TRUNCATE command. If this option is used for a DBMS that does not support TRUNCATE or where the target table(s) cannot be truncated due to other restrictions, an error will occur.

Defines how the data should be sent to the database. Possible values are INSERT, UPDATE, 'INSERT,UPDATE' and 'UPDATE,INSERT'. Please refer to the description of the WbImport command for details on.

If this option is enabled -syncDelete=true, SQL Workbench/J will check each row from the target table if it's present in the source table. Rows in the target table that are not present in the source will be deleted. As this is implemented by checking each row individually in the source table, this can take some time for large tables. This option requires that each table in question has a primary key defined.

Combined with an UPDATE,INSERT or UPDATE,INSERT mode this creates an exact copy of the source table.

If more than one table is copied, the delete process is started after all inserts and updates have been processed. It is recommended to use the -checkDependencies parameter to make sure the deletes are processed in the correct order (which is most probably already needed to process inserts correctly).

To only generate the SQL statements that would synchronize two databases, you can use the command WbDataDiff

Defines the key columns for the target table. This parameter is only necessary if import is running in UPDATE mode. It is ignored when specifying more than one table with the -sourceTable argument. In that case each table must have a primary key.

It is assumed that the values for the key columns will never be NULL.

Possible values: true, false

Controls if identity or auto-increment columns will be included in the import.

If this is used, the JDBC driver (of the target database) must correctly report the column to be excluded as an AUTOINCREMENT column. This can be verified in the table definition display of the DbExplorer. If the column is reported with YES for the AUTOINCREMENT property, then this column will be excluded during the import.

Enable the use of the JDBC batch update feature, by setting the size of the batch queue. Any value greater than 1 will enable batch modee. If the JDBC driver supports this, the INSERT (or UPDATE) performance can be increased.

This parameter will be ignored if the driver does not support batch updates or if the mode is not UPDATE or INSERT (i.e. if -mode=update,insert or -mode=insert,update is used).

Valid values: true, false

When using the -batchSize parameter, the -commitEvery is ignored (as not all JDBC drivers support a COMMIT inside a JDBC batch operation. When using -commitBatch=true SQL Workbench/J will send a COMMIT to the database server after each JDBC batch is sent to the server.

Defines the behaviour if an error occurs in one of the statements. If this is set to true the copy process will continue even if one statement fails. If set to false the copy process will be halted on the first error. The default value is false.

With PostgreSQL continueOnError will only work, if the use of savepoints is enabled using -useSavepoint=true.

Possible values: true, false

Controls if SQL Workbench/J guards every insert or update statement with a savepoint to recover from individual error during import, when continueOnError is set to true.

Using a savepoint for each DML statement can drastically reduce the performance of the import.

Possible values: true, false

If this parameter is set to true, values from CHAR columns will be trimmed from trailing whitespace. This is equivalent to the Trim CHAR data in the connection profile.

Valid values: true, false, <numeric value>

Control the update frequence in the status bar (when running in GUI mode). The default is every 10th row is reported. To disable the display of the progress specify a value of 0 (zero) or the value false. true will set the progress interval to 1 (one).

The name of the schema to be copied. When using this parameter, all tables from the specified schema are copied to the target. You must specify either -sourceSchema, -sourceTable or -sourceQuery

The name of the table(s) to be copied. You can either specifiy a list of tables: -sourceTable=table1,table2. Or select the tables using a wildcard: -sourceTable=* will copy all tables accessible to the user. If more than one table is specified using this parameter, the -targetTable parameter is ignored.

The tables listed in this parameter will not be copied. This can be used when all but a few tables should be copied from one database to another. First all tables specified through -sourceTable will be evaluated. The tables specified by -excludeTables can include wildcards in the same way, -sourceTable allows wildcards.

-sourceTable=* -excludeTables=TEMP* will copy all tables, but not those starting with TEMP.

This parameter supports auto-completion.

When copying more than one file into tables with foreign key constraints, this switch can be used to import the files in the correct order (child tables first). When -checkDependencies=true is passed, SQL Workbench/J will check the foreign key dependencies for the tables specified with -sourceTable

If this parameter is set to true the target table will be created, if it doesn't exist. Valid values are true or false.

Using -createTarget=true is intended as a quick and dirty way of creating a target table "on the fly" during the copy process. Tables created this way should not be considered "production-ready". The created tables will only have the primary key and not-null constraints created. All other constraints from the source table are ignored. Because the automatic mapping of table definitions will only work in the most simple cases this feature is not suited to synchronize the table definitions between two different DBMS products. Because of these limitations this feature can not considered a replacement for a proper schema management. If you have the requirement to keep the schema definition of different DBMS in sync please consider a tool like Liquibase or Flyway. Do not try to use WbCopy for this. If you want to migrate a table (or several tables) from one DBMS to another, consider user WbSchemaReport together with an XSLT transformation

When using this option with different source and target DBMS, the information about the data types to be used in the target database are retrieved from the JDBC driver. In some cases this information might not be accurate or complete. You can enhance the information from the driver by configuring your own mappings in workbench.settings. Please see the section Customizing data type mapping for details.

If the automatic mapping generates an invalid CREATE TABLE statement, you will need to create the table manually in the target database.

Valid values are true or false.

This parameter is only valid in combination with -createTarget=true. If set to true, any default value (or expression) defined on the source table will be ignored when creating the target table. This is useful if the source and target DBMS use different syntax for default values.

When -createTarget is set to true, this parameter can be used to control the SQL statement that is generated to create the target table. This is useful if the target table should e.g. be a temporary table

When using the auto-completion for this parameter, all defined "create types" that are configured in workbench.settings (or are part of the default settings) are displayed together with the name of the DBMS they are used for. The list is not limited to definitions for the target database! The specified type must nonetheless match a type defined for the target connection. If you specify a type that does not exist, the default CREATE TABLE will be used.

For details on how to configure a CREATE TABLE template for this parameter, please refer to the chapter Settings related to SQL statement generation

Normally WbCopy will check if the specified target table does exist. However, some JDBC drivers do not always return all table information correctly (e.g. temporary tables). If you know that the target table exists, the parameter -skipTargetCheck=true can be used to tell WbCopy, that the (column) definition of the source table should be assumed for the target table and not further test for the target table will be done.

Possible values: false, true, cascade

If this parameter is set to true the target table will be dropped before it is created.

For database systems that support it (Oracle, PostgreSQL), a DROP ... CASCADE is used when the value cascade is specified. If the DBMS does not support cascading drops, this is the same as specifying true.

Defines the columns to be copied. If this parameter is not specified, then all matching columns are copied from source to target. Matching is done on name and data type. You can either specify a list of columns or a column mapping.

When supplying a list of columns, the data from each column in the source table will be copied into the corresponding column (i.e. one with the same name) in the target table. If -createTarget=true is specified then this list also defines the columns of the target table to be created. The names have to be separated by comma: -columns=firstname, lastname, zipcode

A column mapping defines which column from the source table maps to which column of the target table (if the column names do not match) If -createTarget=true then the target table will be created from the specified target names: -columns=firstname/surname, lastname/name, zipcode/zip Will copy the column firstname from the source table to a column named surname in the target table, and so on.

This parameter is ignored if more than one table is copied.

Possible values: true, false

For DBMS that support sequences which are associated with a column, this parameter can be used to adjust the next value for the sequence to the maximum value of the imported data. This can also be used to synchronize identity columns for DBMS that allow overriding the generated values.

Currently this is implemented for PostgreSQL, DB2 (LUW), H2 Database and HyperSQL (aka HSQLDB).

-preTableStatement -postTableStatement

This parameter defines a SQL statement that should be executed before the import process starts inserting data into the target table. The name of the current table (when e.g. importing a whole directory) can be referenced using ${table.name}.

To define a statement that should be executed after all rows have been inserted and have been committed, you can use the -postTableStatement parameter.

These parameters can e.g. be used to enable identity insert for MS SQL Server:

-preTableStatement="set identity_insert ${table.name} on"
-postTableStatement="set identity_insert ${table.name} off"

Errors resulting from executing these statements will be ignored. If you want to abort the import in that case you can specify -ignorePrePostErrors=false and -continueOnError=false.

These statements are only used if more than one table is processed.

Possible values: true, false

Controls the execution of the post-table statement in case an error occurred while importing the data. By default the post-table statement is executed even if the import was not successful. If this is should not happen, use -runTableStatementOnError=false.

Possible values: true, false

Controls handling of errors for the SQL statements defined through the -preTableStatement and -postTableStatement parameters. If this is set to true (the default), errors resulting from executing the supplied statements are ignored. If set to false then error handling depends on the parameter -continueOnError.

The SQL query to be used as the source data (instead of a table).

This parameter is ignored if -sourceSchema or -sourceTable is specified.

The list of columns from the target table, in the order in which they appear in the source query.

If the column names in the query match the column names in the target table, this parameter is not necessary.

If you do specify this parameter, note that this is not a column mapping. It only lists the columns in the correct order .