-
Notifications
You must be signed in to change notification settings - Fork 16
Users Guide
This page is intended to cover the basic-day-to-day usage of JSqsh. It assumes that you have already performed the steps covered in Getting Started.
As you type text at the prompt of jsqsh, each line you type is accumulated into a SQL buffer (strictly speaking JSqsh has no idea that you are even typing SQL) until one of the following conditions occurs:
- It looks at the first word you entered on the line to see if it is a command that it recognizes, like go or \help, if it is then it executes the command (run
\help commands
to see a list of all available jsqsh commands). - It looks at the end of the line you just entered to see if it ends with the statement terminator (a semicolon by default), if it is then the statement is executed (this behavior is covered in detail here).
For example, in the following:
1> select count(*)
2> from sysibm.systables
3> go
+--------+
| 1 |
+--------+
| 236 |
+--------+
1 row in results(first row: 0.0s; total: 0.0s)
The first two lines were accumulated into the SQL buffer until the "go" command was executed. The "go" command takes whatever was in the buffer and executes it through the current database connection.
It is important to note that jsqsh tries to be pretty smart about what you are doing, and does attempt to recognize if you in the middle of a comment or a quoted string and will not recognize commands or the statement terminator while within them, for example:
1> select 'in an open string
2> go
3>
the "go" will not execute the statement because you are currently inside of a string literal, similarly,
1> select count(*) from sysibm.systables /*
2> go
3>
the "go" will not run because you are inside of a comment.
While jsqsh supports command line editing (using the arrow keys to move around the current line or to recall previous lines, sometimes you want to edit the entire query that you are in the middle of entering. For this you can use the jsqsh \buf-edit command to pull up the current buffer in an external editor:
1> CREATE PROCEDURE P1 (IN V1 INT, OUT V2 INT)
2> LANGUAGE SQL
3> BEGIN
4> SET V2 = V5 * 2; -- Oops, "V5" isn't a valid variable
5> \buf-edit
The \buf-edit command figures out which editor to launch with your SQL by:
- It looks at the environment variable called EDITOR
- It that isn't set, it looks at the environment variable VISUAL
- If that isn't set, it runs "notepad.exe" on windows, or "vi" on all other systems
The editor will then be pulled up with the contents of the current SQL buffer, like so:
At which point you can edit and even finish your statement and save and quit out of the editor, at which point you will find yourself back at the jsqsh prompt, with the current SQL Buffer reflecting the change you just made:
1> CREATE PROCEDURE P1 (IN V1 INT, OUT V2 INT)
2> LANGUAGE SQL
3> BEGIN
4> SET V2 = V1 * 2; -- All better now
5>
Because \buf-edit it is a bit of a handful to type, jsqsh comes in with two built-in aliases for the command called vi and emacs
1> select kount(*) from
2> vi
note that whether or not you use vi or emacs you are really calling \buf-edit and it is going through the steps described above to figure out which editor to launch!