Sometimes when I work with a new tool for the first time, I find myself amazed at its ingenuity. On seeing a feature I really like, I've been known to exclaim, "That makes so much sense!" Fact is, I'm a bit of a tool-aholic -- I like to have plenty of them. I'm sort of a Swiss Army knife kind of guy, too -- I like single tools that do lots of things. It's just that I like having a bunch of them.
The initial euphoria of trying out a tool for the first time is usually followed by one of two emotions. Either the tool is truly exceptional and I continue to find features that both amaze and impress me, or I end up feeling a bit let down, a victim of the old bait-and-switch routine. My initial feeling after working with Sylvain Faust's SQL-Programmer 2.0 is somewhere between those extremes. The product does have a lot of promise -- I liked many of version 2.0's features. On the other hand, the product is about as bad as it is good. A number of poor design decisions, bugs, and other quirks make the product less than ideal and less functional than its competitors.
Once I completed the first leg of the installation process, I then had to install a separate platform-specific driver. SQL-Programmer 2.0 supports three DBMS platforms: Sybase SQL Server (versions 4.2 through System 11), Oracle (version 7 and above), and Microsoft SQL Server (versions 4.2 through 6.5). Once the initial installation process was finished, I had to run a separate installation to install support for my particular DBMS platform. This second installation routine is unnecessary -- it should be combined with the first one. After all, SQL-Programmer's install routine was created with the WISE Installation System -- it couldn't have been that hard to set up.
Another problem is that the connection dialog doesn't list the currently available server aliases. Instead, I must type in the name of each alias the first time I connect to it. The combo box that lets me select a server alias should already list all available aliases.
A final thing that's missing from SQL-Programmer's connection dialog is a warning when you use the default passwords for DBA or SA accounts. On Oracle, CHANGE_ON_INSTALL is the default password for the SYS account, and MANAGER is the default for the SYSTEM account. When either of these passwords is used, SQL-Programmer should warn you that you're using a system-supplied default password and offer you the opportunity to change it. SQL-Programmer is not alone in this flaw -- neither Platinum Technology Inc.'s Desktop DBA nor Embarcadero Technologies Inc.'s DBArtisan guard against it, but they should.
Once inside SQL-Programmer itself, I was presented with a blank screen with a menu and toolbar at the top. Most users would begin by opening SQL-Programmer's database Explorer. SQL-Programmer 2.0's Explorer provides a Windows Explorer-like interface to your database server. In my case, it was an Oracle7.3 Workgroup Server I'd installed just for evaluating SQL-Programmer. It seems to me that the Explorer should be open by default. At the very least, the software should remember which windows were open when it was last closed down and reopen them when restarted. As it is, no windows are open by default, nor does the program remember what windows were open the last time you ran it.
One problem the software had, both within the Explorer and elsewhere, was an inability to handle large fonts. About a quarter of the programs I use have a problem with large fonts, and SQL-Programmer is the first DBA tool I've used that exhibits this problem. I had to switch to small fonts in order to see the entirety of some of SQL-Programmer's dialogs.
All told, I found the Explorer interface easy to use and, for the most part, intuitive. I'd appreciate the ability to drill down into Oracle tablespaces to access their objects. It's not uncommon for Oracle DBAs to set up a number of tablespaces residing on separate physical drives in order to maximize performance. When tables and indexes are organized in this way, it's helpful to be able to access the objects that live on a particular tablespace.
Free SQL! also exhibits a number of quirks that make it more difficult to use than it should be. Don't bother including the semicolon (";") statement terminator in Oracle SQL statements you write; Free SQL! doesn't know how to handle it. If you try to execute an Oracle SQL statement that's terminated with a semicolon, you'll get an error message from your server. SQL-Programmer passes the semicolon directly to the server instead of recognizing it as a statement terminator and removing it -- an annoying flaw.
Free SQL! is missing a few features that I think a full-blown SQL editor should have: SQL syntax highlighting, vendor-specific SQL help, and support for regular expressions in searches. Until these features are added, SQL-Programmer doesn't really offer anything to lure you in this area.
SQL-Programmer pulls off the magic of Batch Objects by supplying its own extensions to SQL to work with them. Specifically, it adds the CREATE BATCH, DROP BATCH, and EXECUTE BATCH statements to the language. These commands are intercepted by SQL-Programmer when you attempt to execute them via Free SQL! and processed internally by the program. As long as you use SQL-Programmer to perform your SQL editing, these new commands will seem like a part of SQL itself.
I found SQL-Programmer's Batch Object support one of its more intriguing features. Storing SQL source entirely on database servers is an interesting idea. We'll see if it catches on.
I got the distinct impression that the tool was designed primarily to work with Sybase's SQL Server -- and that Oracle support was an afterthought. In fact, version 1.x of SQL-Programmer supported Sybase and Microsoft SQL Server, but not Oracle -- that happened in version 2.0. At this point, the support for Oracle still seems half-baked. For example, when generating the DDL for an Oracle table with a comment associated with it, SQL-Programmer generated Oracle PL/SQL with embedded SQL Server ISQL go commands! Needless to say, the generated SQL script wouldn't execute properly in Oracle's SQL*Plus tool. The same thing happened again when I generated the DDL for several objects at once. SQL-Programmer delimited each SQL create statement with SQL Server gos. This made the generated scripts very difficult to use with other Oracle tools -- a real shame considering some of the product's other bright spots.
Another problem with the SQL generation facility reared its ugly head when I reverse-engineered an Oracle tablespace. The facility didn't recognize that the structure had been created with the AUTOEXTEND option turned on; hence it didn't generate the correct SQL. Running the SQL it generated would have resulted in a tablespace definition that differed from the original.
A final problem I had with the scripting facility was with its ineptness when generating whole schema SQL scripts. I selected several schemas in the Script Engine facility and chose the ScriptNow menu option. I expected to get a single SQL script file containing all of the SQL necessary to completely recreate each schema. Instead, I got a script file containing a set of CREATE statements that simply recreated the user accounts associated with the schemas. If you intended to save off your database's structure before making some sort of radical change to it, you'd be out of luck if you relied on SQL-Programmer's scripting facility to reconstruct it. Despite several attempts, I could find no easy way to build an all-encompassing CREATE script for even a single schema, let alone an entire server.
A feature completely missing from the SQL-Programmer help system is vendor-specific SQL help. Having the vendor's core SQL syntax in the help system can save you a trip through server manuals or your vendor's online documentation. I'd find SQL-Programmer much more useful if it included essentials such as these.
