The edit tab contains the DDL for the object.  The Prologue or Epilogue tabs are used to enter SQL that will be executed before and after a procedure.  This gives a developer to setup a complete test and see the results all within one test.  This can also be saved to an SPDW file in the next release, so that you can setup multiple tests and compare the results between them.  The arguments tab lists all of the arguments for the procedure.   The results tab is where any results are displayed.  An errors tab shows any errors in the batch.  Simply double clicking on an error takes you to the appropriate line in the editor.  I can't recall what the privileges tab showed, but the dependencies shows all of the dependent objects for the object being edited.   Finally, the activity log is a nice touch.  There are times when you might execute a script multiple times.  The activity log tracks each execution. 

In addition to all of the information contained in the editor, there is one feature that really shows the developers of SQL-Programmer have done a lot of development work.   I can't recall how many times I've modified an object and then went to replace it in the database only to get a syntax error.  The syntax errors are not a problem and can be fixed.  The problem is that you just dropped the only good copy you had and you are now missing and object until you can track down all of the errors.  This can take quite a bit of time and usually doesn't impact your environment.  But, what happens when you have a procedure out there that controls something like security access to database objects.  Every time a call is made to the database, it must pass through this object.  You've now brought a development or production environment to a grinding halt simply because there is a syntax error that is usually something as simple as misspelling an object name.  SQL-Programmer prevents this by validating the syntax.  Only if the syntax is clean and the object will recompile in the database does it then drop the old object and replace it with your modified one.  I'd have to give the people at SFI and big thank you for this simple little feature that is really nothing more than executing the script with a parse only option.  Unfortunately, every other development tool overlooks this simple little fact.

SQL-Programmer packs a relatively simple search facility.

You can search for the existence of a string within a single database.  This is generally sufficient.  However, I would have liked to see something like the more robust search engine in DBArtisan that allows searching of multiple database, multiple servers, and multiple DBMSes for the existence of a string.  I would have also like to see the ability to do wild card searches and advanced searching where you can specify a string or pattern of text while at the same time excluding particular strings from the results.  An example of this was our recent odyssey with having = null instead of is null inside a pile of triggers and stored procedures.  Inside a set clause, = null is perfectly legal and is the proper syntax.  However within a where clause it is not.   It would have been nice to search for all occurrences of = null while excluding the occurrences within a set clause.  Do I expect to see this level of search functionality simply because I asked for it and posted this review for everyone to see?   No.  But, it never hurts to ask.  Afterall if you don't ask for a feature, you will never have the possibility of getting it.

SQL-Programmer 2.2 1 2 3 4 5 6 7