KeepTool 12.1 released


Welcome to the KeepTool newsletter for July, 2016. This month, we are pleased to announce the release of KeepTool Version 12.1.0. The new version offers several ways to simplify your coding efforts, as well as the addition of a “license borrowing” function for network licenses.

New “license borrowing” function for using KeepTool 12 outside the network

This feature is designed to let owners of network licenses use KeepTool away from a local network for up to 30 days.

The “borrowing” facility can be invoked by starting the Wibu License Manager in any of three ways:

  • Running “License Manager – Borrowing” from the Windows Start Menu:
  • Running KeepTool Start Center, clicking “License Management”, then clicking the  “Borrow / Return License “ button
  • Clicking “Help | License Management | License Manager / Borrowing” from Hora’s main menu

Once the License Manager is opened, you will be asked whether you want to borrow a license for KeepTool 12 Professional and/or the Enterprise Tool Add-Ons (if you have the Enterprise Edition), as shown here:

License Manager

You can set a period of up to 30 days for which to borrow the license, with 3 days being the default. This gives you the full use of your KeepTool license, just as if you were still connected to your company’s network. You can also return the license early, but on the selected expiration date, the license will be returned automatically.

Incidentally, you can use decimals to define smaller intervals such as 0.5 for 12 hours.

Next, we’ll cover some ways in which Version 12.1 makes coding of SQL and PL/SQL more convenient:

Hora’s SQL Scratchpad now persists query parameters and lexical parameters for each DB connection

When executing a SQL statement, some actual values may be provided at run time through the use of query parameters (i.e. bind variables) and lexical parameters (i.e. macros). After a statement is saved in the Scratchpad, the previous values used by the same user and connection string are suggested the next time that the statement is run.

Here’s an example from a schema that we have cloned from the HR sample schema. For HR1, we’ve created a view on the EMPLOYEES table that includes only a subset of employees, so that we can execute this SQL on either the entire EMPLOYEES table or the V_ST_CLERK view that contains only one job_id. A lexical parameter, beginning with an ampersand, is being used in the FROM clause.

Likewise, we may want to use a query parameter, beginning with a colon, for the value of SALARY. By using a query parameter, we may eliminate extra parsing of SQL in the shared SQL area before re-executing the statement.

The file can be saved like this, with the results shown below the code window:

SQL Query Result

The next time that HR1 logs in with the same connection string, and the SQL is submitted for execution, the previously used values are suggested, allowing those to be used if desired, or modified.

SQL Query Result SQL Query Result

PL/SQL page now shows red bullets next to erroneous lines

Hora’s PL/SQL page lists all PL/SQL errors below the source code. The new version adds a red bullet (square) in the gutter area in the left of each erroneous source code line. This makes it easier to locate the error position. In the following example, both lines 11 and 17 have been flagged by the compiler.

PL SQL Debugging

SQL generation now shares common behavior in all locations

Hora has long had the ability to generate various DML statements, as well as CURSOR FOR LOOPs and WHERE clauses:

  • For a table selected in Overview Tables
  • For a table selected in the editor window
  • For a table name dragged from the DB object browser into the editor window.

In each of these three situations, SQL generation now works in a similar fashion.

Now the INSERT statement option contains a new “Default Values” checkbox that gives special treatment to those with DEFAULT values and NULL columns. To show this, we’ve cloned the HR.EMPLOYEES table and given a default value of ‘PENDING’ to the EMAIL column, which is NOT NULL.

If we leave the Default Value checkbox (shown below) unchecked:

Insert Default

then the resulting INSERT statement uses query parameters for each column, as in the first example below.

On the other hand, if the box is checked, then the INSERT statement assigns the default value for EMAIL along with NULL for all nullable columns as in the second example:

Insert Statement

To sum up:

This option for the INSERT statement assigns default or null values to as many columns as possible. It gives the user a clear indication of which columns must be populated (NOT NULL) and which default values will be populated if no other values are explicitly coded. Before inserting a row, you need to determine whether to allow the default or null values as presented in the example, or whether to supply your own.


That’s it for this issue of Keeping in Touch. In our October issue, we’ll be introducing some other new features of Version 12.1, as well as looking at some previously existing functionality that may not be all that familiar.