What's in the Interbase/bin directory?Usually, for Windows users, what IB shows as the available included tools are the graphical ones, but there're more. In IB5, the GUI face was Server Manager. It appeared in IB4 on Windows because there was a need to administer IB servers on Netware and at that time, writing a 16-bit GUI tool that could talk to both IB4 on Windows3.1 and IB4 on Netware was deemed easier than fighting with NLM complexities to create a loadable module for administration inside Netware itself. Incidentally, this is the origin of the first (and undocumented) Services API, because Server Manager needed to talk to both local and remote IB servers. In IB4, Server Manager had a very fixed UI, but it worked. For IB4.1 on Windows, the GUI tools were revised to become 32-bit executables. In IB5, the Server Manager window was made resizable and other minor improvements happened. One nicety of the IB4/IB5 GUI was the presence of the small program known as WISQL, that could be used directly or invoked from Server Manager, too. Although basic, it allowed to get metadata information, send individual SQL commands to the engine, replay commands, log output and submit full scripts to the engine. To complete the battery of GUI tools, there was the Communication Diagnostics Utility, to troubleshoot network problems between clients and the engine. In IB6 on Windows, drastic changes happened. First, Server Manager was deprecated and wasn't included as part of the distribution. Indeed, it wasn't updated to talk to IB6. It was superseded by the [in]famous IBConsole, a can of worms that intends to be all-in-one for all GUI lovers. While IBConsole GUI is more flexible because it's written in Delphi5, it's not free of its own quirks. First, the lightweight Communication Diagnostics is no more a tiny independent utility that one can carry on a 1.44 diskette, but it's one window inside IBConsole. Also, the WISQL utility had the same fate: it's another window inside IBConsole and can't be activated alone. Problems and bugs aside, IBConsole has some improvements over Server Manager: the hierarchy of database objects shows in the left page as a graphical tree allows to be connected to more than one database simultaneously and to switch between them quickly. Inside each database, the available objects are categorized. The child windows can be resized and metadata for an object can be reached in a simpler way than with Server Manager's options and drop downs. One confusing decision was to include a tiny application, called IB Server Manager. It has nothing to do with the classic Server Manager; the new application is small a helper to configure IB startup mode between manual and automatic and between service and application. Now, on the console-mode or text based utilities. They are in the bin directory, waiting to be discovered and used. They are almost from day one on Interbase history. UNIX people that use IB are very familiar with those applications, but Windows users usually prefer to push buttons in GUI applications and reboot 15 times a week in average. (BTW, I use NT, so I'm not as heavily affected as Win9X users.) These utilities are described in the Operations Guide that comes with IB. isql.exe is the console-mode equivalent of WISQL. Of course, it doesn't have a menu nor buttons. It can connect to only one database at the time. But it has a powerful set of commands, it can change the isolation level with all the options that are allowed in DSQL to start a transaction, it can run scripts almost flawlessly, it obeys a character set (SET NAMES) provided that you specify it before connecting to a db, it extracts scripts very well and it's the DE-FACTO utility to test SQL commands and to measure other utilities against it. Also, it has a set of "macros", namely, commands that only this utility understands and that are shortcuts to get metadata information. When in doubt whether your command is correct or not, test it with isql.exe to see what happens, but remember that any command should be finished by a terminator that's a semicolon by default. gbak (whose internal name is BURP) is the utility that backs up and restores databases. It has plenty of options for those tasks. It's useful when facing corruption, too: usually it's possible to recover a db by backing up without garbage collection. When a constraint has conflict with data and the problem is detected after the backup, restoring without validity constraints saves the day. Since IBConsole versions before v310 have problems when backing up, gbak was the solution. gfix (whose internal name is ALICE) is the utility that implements "all else" and hence its name. It allows to fix a corrupted database, although its power is limited. It can activate a shadow, put the database in single user mode (shutdown) and again online (restart), resolve limbo transactions (those that appear in multi-database transactions), set number of page buffers for each database (to be used when attaching to a db), enable or disable forced writing (sync/async writing to disk), do a sweeping and set the sweeping interval. Also, in IB6, new capabilities were added: to put a db in RO or RW mode and to set the database dialect. gpre is the preprocessor. In the neolith, there was a strong differentiation between dynamic applications and static applications (embedded SQL). The latter were more common and they were written in an application language whose sources were passed through gpre before being converted in machine code by the language compiler. So, the IB instructions were compiled into static BLR inside the application. At that time (IB3.X), dynamic application relieds on the DSQL utility that ran in the client side to generate BLR from the dynamic SQL it read. Starting with IB4.0, DSQL was incorporated as a subsystem inside the core engine so it became a server-side component. The static feature of IB has survived in gpre throughout the years and gpre is able to preprocess Ada, C, C++, COBOL and Pascal, depending on the platform. Now, dynamic applications are the most common usage of IB through SQL. gsec is the security utility. It connects to the user password database in IB. There's one security database per engine, so any user that can authenticate with an IB server can access any db that's local to such server. The gsec utility can display all users, one user, modify a user, add a user, delete a user but it can't create, modify or delete roles, because roles go in each database and gsec only connects to the security database is4.gdb whose name has remained since IB4.0, because there has not been any important upgrade since then to justify a name change. gstat is the utility to gather statistics about a database. It analyzes the internal layout, like the fill factor, header page, index pages, log page and system relations. In addition, between the time IB6 was in beta and the time IB6 was released, two new undocumented flags were added by Charlie Caro:
iblockpr is the utility that reads and interprets the content of the locks file server_name.lck that's created when IB is running and there's at least one attachment. The files takes the name of the server machine where IB is running. If the file doesn't exist yet or it was deleted because IB is not running, iblockpr shows the message "Unable to read lock table version 0." The locks file is the file that holds the locks the engine keeps to protect resources, examples of them are pages being updated and generators being changed. gdef (whose internal name is DUDLEY) is the original utility that deals with metadata. It can extract metadata, replace an existing database, generate dynamic DDL and emit DYN for Fortran, Pascal, COBOL, ANSI COBOL, basic, PLI, ADA, C and C++. It was removed from the v4.0 distribution and it reappeared in v6 thanks to the Open Source decision. Since isql.exe and the DSQL interface can handle DDL, gdef can be considered redundant except for static applications known also as embedded SQL applications. qli is the original and proprietary isql tool of IB and hence its name means Query Language Interpreter. It speaks GDML and also understands SQL (including DDL), but its SQL interface has not been revised in the latest years. It was removed from the v4.0 distribution and it reappeared in v6 thanks to the Open Source decision. Its value comes from the fact that it can connect to more than one database at the same time and since BLR allows some tricks not possible in SQL, you can simulate multi-database joins, request only the top N records of a select expression and take advantage of the procedural capabilities of BLR. For using it, you need to copy also the help.gdb database that comes with qli to the Interbase/help directory, because qli has its online help inside this IB database. Remember that QLI is specific of each IB version, so qli for v6 doesn't work against IB5.X, for example. Be careful that GDML allows you to modify system tables as well but without a safety net. The new DDL syntax in IB6 performs checks before proceeding, in contrast.
|
|
This page was last updated on 2000-09-18 02:44:50 |