KeepTool 12.1 introduces numerous new features. 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.
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:
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).
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:
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 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.
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.
Hora has long had the ability to generate various DML statements, as well as CURSOR FOR LOOPs and WHERE clauses:
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 unchecked, 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.
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.
Explore possibilities of KeepTool.
