The shell scripts (and the batch files) first check if the environment variable WORKBENCH_JDK is defined. If that variable is defined, the shell script will use $WORKBENCH_JDK/bin/java to run the application.

If WORKBENCH_JDK is not defined, the shell script will check for the environment variable JAVA_HOME. If that is defined, the script will use $JAVA_HOME/bin/java to run the application.

If neither WORKBENCH_JDK nor JAVA_HOME is defined, the shell script will simply use java to start the application, assuming that a valid Java runtime is available on the path.

All parameters that are passed to the shell scripts are passed to the application, not to the Java runtime. If you want to change the memory or other system settings for the JVM, you need to edit the shell script.

First the launcher checks for a system variable WORKBENCH_JDK. If that is defined, the JDK specified by that directory is used. If WORKBENCH_JDK is not found, JAVA_HOME is used. If JAVA_HOME is not defined, then the launcher checks if a sub-directory JRE exists in the folder where SQLWorkbench.exe is located. If that sub-directory exists, it is assumed that it contains a valid JRE. If the sub-directory does not exist, or if it is not a JRE installation, then the registry key HKLM\Software\JavaSoft\Java Runtime Environment is queried. If that is not defined, HKLM\Software\JavaSoft\Java Development Kit is queried.

In the registry key, a subkey for the version 1.6 is retrieved, and the directory specified by that key is used as the base JDK directory.

If your JDK/JRE installation cannot be found by the launcher, but you do have a JDK available, you can specify the location of the JDK with the -jdk parameter

The launcher assumes the layout of the Sun jdk in the specified directory. If you specify c:\jdk as the JDK directory, the launcher looks for the file c:\jdk\bin\client\jvm.dll (the specified directory would actually be a JRE then). If that is not found, it looks for c:\jdk\jre\bin\client\jvm.dll (that would be a "true" JRE installation). If the -sever parameter is specified, it will look for a sub-directory server instead of client. If your non-Sun JDK/JRE follows the same directory layout and filename conventions, you can use the launcher for that JDK as well.

To distinguish parameters for the launcher and parameters to the JVM, JVM parameter need to be prefixed with -J. If you want to pass the parameter -Xmx256m to the JVM, pass the parameter -J-Xmx256m to the launcher. To define a system property you need to pass the parameter -J-Dproperty.name=property_value.

The following parameters are recognized:

All other parameters are passed unchanged to the program. See command line parameters for details.

The following call to the launcher:

SQLWorkbench -noddraw -configDir=c:\MyConf

is the same as directly starting sqlworkbench.jar with these parameters:

java -Dsun.java2d.noddraw=true -jar sqlworkbench.jar -configDir=c:\MyConf

With Windows Vista, Microsoft changed the way needed DLLs are searched when an executable is loaded. This affects the SQL Workbench/J launcher due to the (new?) Microsoft C runtime distribution model. If you want to run SQL Workbench/J under Windows Vista, please copy the file msvcr71.dll into the directory where SQLWorkbench.exe is located.

This file can be found at %SystemRoot%\System32\msvcr71.dll (usually this is c:\Windows\System32\msvcr71.dll)

Thanks to Jon for this tip.

If you want to control the location where SQL Workbench/J stores the configuration files, you have to start the application with the parameter -configDir to specify an alternate directory:

java -jar sqlworkbench.jar -configDir=/export/configs/SQLWorkbench

or if you are using the Windows® launcher:

SQLWorkbench -configDir=c:\ConfigData\SQLWorkbench

java -jar sqlworkbench.jar -configDir=${user.home}/.sqlworkbench

To copy an installation to a different computer, simply copy all the above files to the other computer (the log file does not need to be copied). When a profile is connected to a workspace, the filename of the workspace file is usually stored with a placeholder for the configuration directory (%configDir%) so that the profiles don't need to be adjusted.

You will need to edit the driver definitions (stored in WbDrivers.xml) as the full path to the driver's jar file(s) is stored in the file (unless you define the location of the drivers using the libdir variable.

The parameter -configDir specifies the directory where SQL Workbench/J will store all its settings. If this parameter is not supplied, the directory where the default location is used. The placeholder ${user.home} will be replaced with the current user's home directory (as returned by the Operating System). If the specified directory does not exist, it will be created.

java -jar sqlworkbench.jar -configDir=${user.home}/wbconfig
SQLWorkbench -configDir='c:\Configurations\SQLWorkbench'

On the Windows platform you can use a forward slash to separate directory names in the parameter.

The -libdir parameter defines the base directory for your JDBC drivers. The value of this parameter can be referenced when defining a driver library using the placholder %LibDir% The value for this parameter can also be set in the file workbench.settings.

SQL Workbench/J stores the connection profiles in a file called WbProfiles.xml. If you want to use a different filename, or use different set of profiles for different purposes you can define the file where the profiles are stored with the -profilestorage parameter.

If the value of the parameter does not contain a path, the file will be expected (and stored) in the configuration directory.

With the -vardef parameter a definition file for internal variables can be specified. Each variable has to be listed on a single line in the format variable=value. Lines starting with a # character are ignored (comments). the file can contain unicode sequences (e.g. \u00fc. Values spanning multiple lines are not supported. When reading a file during startup the default encoding is used. If you need to read the file in a specific encoding please use the WbVarDef command with the -file and -encoding parameter.

#Define some values
var_id=42
person_name=Dent
another_variable=24

If the above file was saved under the name vars.txt, you can use those variables by starting SQL Workbench/J using the following commandline:

java -jar sqlworkbench.jar -vardef=vars.txt

You can also define a list of variables with this parameter. In this case, the first character after the = sign, has to be # (hash sign) to flag the value as a variable list:

java -jar sqlworkbench.jar -vardef=#var_id=42,person_name=Dent

Defining variable values in this way can also be used when running in batch mode.

If the -nosettings parameter is specified, SQL Workbench/J will not write its settings to the file workbench.settings when it's beeing closed. Note that in batch mode, this file is never written.

	If this parameter is supplied, the workspace will not be saved automatically as well!

You can specify the name of an already created connection profile on the commandline with the -profile=<profile name> parameter. The name has to be passed exactly like it appears in the profile dialog (case sensitiv!). If the name contains spaces or dashes, it has to be enclosed in quotations marks. If you have more than one profile with the same name but in different profile groups, you have to specify the desired profile group using the -profilegroup parameter, otherwise the first profile matching the passed name will be selected.

Example (on one line):

java -jar sqlworkbench.jar
     -profile='PostgreSQL - Test'
     -script='test.sql'

In this case the file WbProfiles.xml must be in the current (working) directory of the application. If this is not the case, please specify the location of the profile using either the -profilestorage or -configDir parameter.

If you have two profiles with the names "Oracle - Test" you will need to specify the profile group as well (in one line):

java -jar sqlworkbench.jar
     -profile='PostgreSQL - Test'
     -profilegroup='Local'
     -script='test.sql'

You can also specify the full connection parameters on the commandline, if you don't want to create a profile only for executing a batch file. The advantage of this method is, that SQL Workbench/J does not need the files WbProfiles.xml, WbDrivers.xml to be able to connect to the database.

The connection can be specified with the following parameters:

If a value for one of the parameters contains a dash or a space, you will need to quote the parameter value.

A disadvantage of this method is, that the password is displayed in plain text on the command line. If this is used in a batch file, the password will be stored in plain text in the batch file. If you don't want to expose the password, you can use a connection profile and enable password encryption for connection profiles.