squirrel-sql-develop Mailing List for SQuirreL SQL Client (Page 50)

Great to have you involved, Patrick.  I am not familiar with either 
BuildMagic or JBOSS, but I am interested.

At 10:41 AM 11/19/01 -0800, Patrick Lacson wrote:
>Colin,
>
>Hello everyone!  Colin, thanks for getting me onboard and I look forward
>to contributing to this cool project!  FYI, Colin and I have been
>discussing a build structure and possibly using the BuildMagic system
>that the JBOSS group uses, for simplification and ease of use.
>
>Colin, as it turns out from our last discussion, a lot of the work
>you've done in the CVS checkin of squirrel-sql can be easily ported to
>the buildmagic semantic.
>
>The BuildMagic tree structure adheres to the following semantic:
>
>modified files for project
>--------------------------
>./build.xml (obvious)
>./project.xml (this is where all your project specific information is
>stored)
>
>buildmagic system files
>-----------------------
>./build.sh (script that uses the bundled ant lib instead of local ant)
>./etc/buildmagic/common.xml (system tree structure defaults)
>./etc/buildmagic/init.xml (system init defaults)
>
>source code info
>----------------
>./src (source tree)
>./src/main (main src tree)
>./src/bin (executable scripts, batch files, etc)
>./src/etc (config files required for compilation or release)
>
>external tools and lib
>----------------------
>./thirdparty (thirdparty applications/libraries like ice, izPack,
>jdbc-drivers, etc.)
>./tools (tools used for development testing such as junit, etc.)
>
>compile info
>------------
>./output/build/classes (all files that are compiled from ./src/main
>./output/build/lib (contains the jar file when ./build jar is used)
>
>release info
>------------
>./output/build/release/<version>-squirrel-sql/ (common doc and info)
>./output/build/release/<version>-squirrel-sql/bin (contains and
>executables)
>./output/build/release/<version>-squirrel-sql/classes (compiled
>byte-code)
>./output/build/release/<version>-squirrel-sql/api (java-doc files)
>./output/build/release/<version>-squirrel-sql/lib (bundled squirrel.jar)
>
>Basically this will keep things in a logical and intuitive structure.
>When we do a release a structure similar to 'release info' will be
>provided, granted that ./output/build/release/<version>-squirrel-sql is
>the root of tree.  This is the structure that BuildMagic uses which we
>use here at work.  Does anybody have any questions or comments?
>
>
>
>--
></Patrick>
>pa...@la...
>
>_______________________________________________
>Squirrel-sql-develop mailing list
>Squ...@li...
>https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop

Colin,

Hello everyone!  Colin, thanks for getting me onboard and I look forward
to contributing to this cool project!  FYI, Colin and I have been
discussing a build structure and possibly using the BuildMagic system
that the JBOSS group uses, for simplification and ease of use.  

Colin, as it turns out from our last discussion, a lot of the work
you've done in the CVS checkin of squirrel-sql can be easily ported to
the buildmagic semantic.

The BuildMagic tree structure adheres to the following semantic:

modified files for project
--------------------------
./build.xml (obvious)
./project.xml (this is where all your project specific information is
stored)

buildmagic system files
-----------------------
./build.sh (script that uses the bundled ant lib instead of local ant)
./etc/buildmagic/common.xml (system tree structure defaults)
./etc/buildmagic/init.xml (system init defaults)

source code info
----------------
./src (source tree)
./src/main (main src tree)
./src/bin (executable scripts, batch files, etc)
./src/etc (config files required for compilation or release)

external tools and lib
----------------------
./thirdparty (thirdparty applications/libraries like ice, izPack,
jdbc-drivers, etc.)
./tools (tools used for development testing such as junit, etc.)

compile info
------------
./output/build/classes (all files that are compiled from ./src/main
./output/build/lib (contains the jar file when ./build jar is used)

release info
------------
./output/build/release/<version>-squirrel-sql/ (common doc and info)
./output/build/release/<version>-squirrel-sql/bin (contains and
executables)
./output/build/release/<version>-squirrel-sql/classes (compiled
byte-code)
./output/build/release/<version>-squirrel-sql/api (java-doc files)
./output/build/release/<version>-squirrel-sql/lib (bundled squirrel.jar)

Basically this will keep things in a logical and intuitive structure. 
When we do a release a structure similar to 'release info' will be
provided, granted that ./output/build/release/<version>-squirrel-sql is
the root of tree.  This is the structure that BuildMagic uses which we
use here at work.  Does anybody have any questions or comments?



--
</Patrick>
pa...@la...

Brad, I've managed to lose your email about this so let me know the bits
I've missed.

I apologize for the way this email has rambled all over the place but I'm
trying to think this through as I'm writing it. Also bear in mind that I've
never used an updateable ResultSet in JDBC so I could easily miss something
obvious.

Currently the SQL output for both the Content tab and the SQL execution
output is built using
net.sourceforge.squirrel_sql.fw.datasetviewer.DataSetViewer. The simplest
description of this class is that it will take a "row based or line based
input" such as a result set and convert it to "row based output" such as a
JTable.

The input must implement IDataSet and the output implement
IDataSetViewerDestination.

ResultSetDataSet is an implementation of IDataSet that displays a
java.sql.ResultSet, and DataSetViewerTablePanel is an implementation of
DataSetViewer that displays data in a JTable.

Currently the opening/closing of the ResultSet is done outside of these
classes.

There would be nothing stopping you from subclassing DataSetViewerTablePanel
to add data editing functionality and using it something like:

DataSetViewer viewer = new DataSetViewer(new
MySubClassOfDataSetViewerTablePanel(myResultSet));
viewer.show(new ResultSetDataSet(myResultSet));

As long as you didn't close myResultSet and it is updateable then from
within MySubClassOfDataSetViewerTablePanel you could do what you like with
it. The current code would just display the result as it currently does.

The next question is how do we hook this into Squirrel?

The easiest way would be clicking on a button brings up a modal dialog with
the updateable table within it but I hate modal dialogs and I think this
would eb very irritating for users of the product.

Another idea would be a menu item or a button that reexecutes the current
SQL script and displays an editable table in place of the current
non-editable table or another tab with an "edit" title. I think I prefer the
replacing the table rather than another tab. Another tab would work for the
content tab but I think it would get very confusing for the SQL entry area.

Frankly I don't like either idea, the first is plain bad and the second
sounds messy. Anybody got any better ideas?

I'm not too keen on just replacing the current table outut with an editable
version of DataSetViewerTablePanel as the user currently has the option to
change the type of output viewer through the session options output tab.
Currently both table and text output is supported and I envision in the
future extending this to other types of output such as HTML by creating new
classes that implement IDataSetViewerDestination.

Something else to bear in mind is that not all JDCB drivers support
updateable result sets and it would be nice to be able to maintain data
through them as well, possibly by generating update scripts manually.

These are just my first thoughts on the subject. Comments, ideas, flames?

Col

Squirrel uses the Ant build tool from Apache
http://jakarta.apache.org/ant/index.html and the IzPack installer from
http://www.izforge.com/izpack/

You need to use at least version 1.4 of Ant.

The scripts supplied with Squirrel for these tools are oriented towards
building the distribution, not towards development. Personally I load the
source into an IDE and let it work out the dependencies.

If you're not familiar with Ant take at look at this JavaWorld article
http://www.javaworld.com/javaworld/jw-10-2000/jw-1020-ant.html

In the build directory there is an Ant build script called build.xml. If you
run it with the "help" target it will give a brief description of the
different targets in the file.

=======================

compile_fw

The classes in the module squirrel-sql/fw are basic framework classes. They
don't know anything about the Squirrel SQL client and could be used for
other applications (if they were more robust). Ant compiles them into a
fw.jar file.

To compile these classes you will need the NanoXML jar which can be found in
CVS at squirrel-sql/fw/lib. As the framework is enhanced it may be that
other third party jars will be required, in which case they will also be
kept here.

=======================

compile_app

The classes in the module squirrel-sql/fw are the actual SQL client
application itself. They rely on the classes and libraries from
squirrel-sql/fw in order to compile.

=======================

compile_plugins

This target will compile all the plugins. For this to work each plugin must
supply an Ant build file called plugin_build.xml. This file must have a
target called "build".

Three parameters are passed to the build target:

p_plugin.work_dir             - defines a work directory that you can use
for work
                                files, E.G. .class files etc.
p_plugin.dist_dir             - direcory to place the plugins jar file and
other
                                files for the plugin.
p_plugin.core_libs_dir        - directory that contains the framework
library jars
                                and the SQuirreL client jar that you will
need to
                                compile your plugin.

For an example plugin_build.xml take a look at the one for the Look and Feel
plugin at /squirrel-sql/plugins/laf/plugin_build.xml

==================================================

The IzPack build process runs from the Windows batch file izpack.bat.
Currently it (and the IzPack config files) have a lot of hardcoding. I
really need to write an Ant task for IzPack.

The IzPack config file izpack-basic.xml builds a basic installer that only
includes the SQL Client. The IzPack file izpack-complete.xml builds an
installer which includes all the plugins as well.

==================================================

I'm going to take this email, enhance it and add it as a section in the
Programmers Guide.

Plugin API mods
---------------
PluginManager.getPluginAppSettingsFolder(IPlugin) and
PluginManager.getPluginUserSettingsFolder(IPlugin) replaced by
IPlugin.getPluginAppSettingsFolder() and
IPlugin.getPluginUserSettingsFolder()

ISession.addSQLExecutionListener() and ISession.removeSQLExecutionListener()
added.

Plugin functionality mods
-------------------------
Integrated Johans code for create table/insert scripts into the sql script
plugin.

Look and Feel plugin now changes the look and feel on the fly.

My daily ramble.

<snip>
I have tried to force myself to use cvs (and wincvs), but have not stuck 
with it.  The old "zip up each day's work" has worked well enough for me, 
unfortunately.
</snip>

Me too... usually. For my personal stuff I've never used any source control,
just zipped it up prior to doing anything major (if I can be bothered).
It'll be interesting to see if I use CVS properly or not.

<snip>
We are currently going through the process of trying to implement a 
configuration system using Rational's products (not my choice, but they 
want to use it and already bought licenses last year).  I appreciate that 
it is almost a full-time job to keep up with that kind of stuff.
</snip>

I don't have any experience with the Rational configuration products, just
their load testing tools. I hope your local support is better than ours. We
found numerous problems with the tool (in fact Rational USA ending up
telling to install a previous release) but the only response from the local
Rational consultant was "you're doing it wrong" without being able to
actually tell us what we were doing wrong - to make it worse the way we'd
set it up was the way recommended by a previous Rational consultant (who DID
know what he was talking about). Rational finally admitted that our problems
were in the tool, not in what we were doing but it was a long road with a
lot of wasted time. Good luck.

<snip>
So, any of us developers can mess with any part of the whole source 
tree?  I don't plan on doing that actually, but I wonder if we want to 
enforce any  kind of regression testing.  Speaking for myself, I plan on 
staying in my own little "plugin" world. 
</snip>

I have to admit I'm uncomfortable (at least in the early days) with others
modifying the core modules. I think of Squirrel as being my little baby girl
(I think I finally understand how my father felt when my 18 yo sister went
to university 600 miles from home). For now what I'd like is for everybody
to 'stay in their own little "plugin" world' as Brad so eloquently put it.
If its your plugin then you own it, the rest of us can make suggestions, say
what we like and dislike but ultimately the functionality, the way you write
the code, everything is your call. Which leads on to...

<snip>
If there's something specific I think should be changed in the main tree,
I'll probably just ask Colin to actually make the change.  This would
provide an additional check on the appropriateness of the change.
</snip>

I'm not saying that I don't want others to make changes to the core, just
that I don't want you to do it directly into CVS. There is a lot of work to
do to the core in terms of writing the plugin API. As you start working with
it you'll realize just how much is missing (much of which I'm sure that I
don't even realize would be required). If you need something in the core for
your plugin first just send a msg to the list and I'll either say "already
doing it - almost finished" or "I've just put it on my todo list" or "I
don't think we should do that, how about...". Once we agree on just what
needs to be done then you might think about making the change yourself and
emailing the changes to the list so that I can integrate them back into the
core. Just let me know any changes you're about to make so that I (or
somebody else) don't start making the same mod. Once I take a look at your
changes I might say "great" and apply the changes or I might say "Great but
how about we enhance it like this..." and so on.

One problem with this emailing back and forth is going to be the time zones.
I'm in Sydney Australia and I know some of you are scattered across the rest
of the world. Turn around on emails is going to take some time so we'll just
have to be patient or everybody could just move to Sydney <grin/>.

Johan has already sent me a lot of changes to the core which are up in CVS,
Guido recently sent me some changes which now that everything has quietened
down I'm going to be looking at. The more people who do this the better
Squirrel gets.

I can see myself for a while at least just integrating other peoples changes
into Squirrel and not doing any real work myself, but if thats whats needed
to get a decent API built into Squirrel then thats what will happen.

I'll sit down over the weekend and work out a list of the next changes I
want to make to the core and put it out on the list so that you all have an
idea of what I'm going to be doing. To be honest I don't know how well I'll
keep to that list as I have a habit of doing whats fun and leaving the other
stuff. We'll just have to see.

One more thing and I'll get off my soapbox. The way I see Squirrel evolving
is more and more functionality being pushed out into plugins. I'd like to
end up with Squirrel being a framework that really doesn't do all that much
itself, all the functionality is in the plugins. How practical that will be
(certainly how practical that will be by evolving the current code base) I
don't know. What I'd like to see eventually is that all Squirrel development
is done in plugins, I don't think that will ever happen but as close to that
as possible is what I would like to aim for.

<snip>
but I wonder if we want to enforce any  kind of regression testing
</snip>

If I'd done Squirrel properly there would already be JUnit test cases set up
etc. When I get some time I should start setting this up. Although I
probably won't...

<snip>
Are there others on the list here who have experience with configuration 
tools and the configuration management process?
</snip>

Just with source management tools E.G. PCVS, RCS and Visual Source Safe. I
find source management very valuable as long as you have somebody
controlling it. Thou shalt not check in code that doesn't compile, thou
shalt not check in code that hasn't been tested, thou shalt set up libraries
of code that are versioned for other projects etc. If you're introducing it
to a development team that hasn't used it before you'll possibly have some
resistance - I can't remember the excuses now but there were some
interesting ones. Reasoned argument usually works, if not then a baseball
bat.

On a side note a friend of mine recently took a job with a nameless
international consultancy here in the Sydney office. His first job was to
set up the build and deployment process for a project. He discovered that
the current build process was:

1. Walk around to every developers desk and ask them to put the code that
they're working on onto a diskette.

2. Copy all the code from the diskettes into a cental location.

3. Compile the code.

4. If it compiled then send it to the client - no testing, the developers
have already done that so theres no need.

5. If it didn't compile go back to step 1.

I guess change management is what you make of it.



A quick word on the directory structure in CVS.

/squirrel-sql/app - The Squirrel client application. 

/squirrel-sql/fw - A base library that Squirrel is built on top of. These
are supposed to be general purpose classes that don't actually know anything
about the Squirrel client. This code is mainly stuff that I've refactored
out of Squirrel.

/squirrel-sql/build - Build scripts etc. for Squirrel.

/squirrel-sql/doc - Some (very little) documentation for Squirrel.

/squirrel-sql/plugins - All your plugins. Each plugin will have a directory
under this one named after its internal name. E.G. the Look and Feel plugin
is in squirrel-sql/plugins/laf. If you start a new plugin just create a
directory in here. Just let me know the internal name that you want to use
before you go creating the directory as there are some rules on what it can
be. See the plugin programmers guide in the doc directory for more info.

squirrel-sql/web-site - the Squirrel web site.



One more thing and then I'll stop. Recently somebody (I think it was Brad
but I can't find the email) asked why refreshing the object tree collapses
it instead of leaving it in its expanded state. The answer is "Dammed if I
know". Theres code in there to save and restore the expansion state but it
isn't working. It appears that the view is out of synch with the model as I
can see the code doing the expansion actually executing but the tree isn't
refreshed. I'm missing something obvious but I can't see what it is. If
somebody wants to take a look the classes involved are 
net.sourceforge.squirrel_sql.client.session.ObjectsTree and the class that
actually does the save/restore is an internal class in ObjectsTree called
SavedExpansionState. I'd really appreciate somebody finding this bug
<desperate begging/>.

Col 

I have tried to force myself to use cvs (and wincvs), but have not stuck 
with it.  The old "zip up each day's work" has worked well enough for me, 
unfortunately.

We are currently going through the process of trying to implement a 
configuration system using Rational's products (not my choice, but they 
want to use it and already bought licenses last year).  I appreciate that 
it is almost a full-time job to keep up with that kind of stuff.

So, any of us developers can mess with any part of the whole source 
tree?  I don't plan on doing that actually, but I wonder if we want to 
enforce any  kind of regression testing.  Speaking for myself, I plan on 
staying in my own little "plugin" world.  If there's something specific I 
think should be changed in the main tree, I'll probably just ask Colin to 
actually make the change.  This would provide an additional check on the 
appropriateness of the change.

Are there others on the list here who have experience with configuration 
tools and the configuration management process?



At 08:32 AM 11/16/01 +1000, Colin Bell wrote:
>A bit of both. I've never used CVS before.
>
>Theres nothing like a learning experience.
>
>-----Original Message-----
>From: squ...@li...
>[mailto:squ...@li...]On Behalf Of
>BradLyon
>Sent: Friday, 16 November 2001 5:37 AM
>To: squ...@li...
>Subject: [Squirrel-sql-develop] odd source cvs tree on sourceforge?
>
>
>I was able to check out the latest source tree using the ssh
>method.  Colin: did you intentionally bury the source WAY down in those
>directories, or did sourceforge do that?  I guess we'll each have our own
>batch file to build with Ant, but it still seemed a little odd.
>
>_______________________________________________
>Squirrel-sql-develop mailing list
>Squ...@li...
>https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop
>
>_______________________________________________
>Squirrel-sql-develop mailing list
>Squ...@li...
>https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop

A bit of both. I've never used CVS before.

Theres nothing like a learning experience.

-----Original Message-----
From: squ...@li...
[mailto:squ...@li...]On Behalf Of
BradLyon
Sent: Friday, 16 November 2001 5:37 AM
To: squ...@li...
Subject: [Squirrel-sql-develop] odd source cvs tree on sourceforge?


I was able to check out the latest source tree using the ssh 
method.  Colin: did you intentionally bury the source WAY down in those 
directories, or did sourceforge do that?  I guess we'll each have our own 
batch file to build with Ant, but it still seemed a little odd.

_______________________________________________
Squirrel-sql-develop mailing list
Squ...@li...
https://lists.sourceforge.net/lists/listinfo/squirrel-sql-develop

I was able to check out the latest source tree using the ssh 
method.  Colin: did you intentionally bury the source WAY down in those 
directories, or did sourceforge do that?  I guess we'll each have our own 
batch file to build with Ant, but it still seemed a little odd.

Some people have been having some problems getting CVS access to Squirrel.
The docs are on SourceForge at http://sourceforge.net/docman/?group_id=1 but
they're very confusing (at least for Windows).

Basically the steps are.

1. Install SSH
2. Install CVS
3. Get them working.

Sounds easy doesn't it?

These notes are for Windows, if you're using Linux you're on your own.

Theres an sfsetup tool at http://sfsetup.sourceforge.net/. It didn't work
for me but it does contain an ssh implementation for Windows. Theres also
Putty http://www.chiark.greenend.org.uk/~sgtatham/putty/ which is the
recommended tool for Windows but I haven't tried it.

I'm using WinCVS from www.cvsgui.org

https://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 is a
guide to setting up ssh under Windows BUT DONT BELIEVE IT ABOUT WinCVS.

This doc https://sourceforge.net/docman/display_doc.php?docid=769&group_id=1
will explain how to setup WinCVS.

The CVSRoot you'll need is
:ext:<user_name>@cvs.squirrel-sql.sourceforge.net:/cvsroot/squirrel-sql

Some gotchas:

-1 If I haven't registered you in the project then you won't be able to SSH
in. So sne me your SF logon name. Even if you sent it previously. If you're
not in the project then I've lost it.

0. IF YOU'RE BEHIND A FIREWALL YOU'RE IN TROUBLE. I'm shouting because it
took me a while to realize this. When I first tried to access SF via SSH I
appeared to be contacting the server but it was rejecting my password. In
fact when I got onto SF support it turned out that I wasn't contacing the SF
server at all, the request didn't appear to be getting out past the
firewall. Obviously not all firewalls will have this problem but bear it in
mind.

1. Some of the doc tells you to create a directory called .ssh in your home
directory. Don't bother, ssh will do it for you and its an exercise in
futility to try to create a directory that starts with a period in Windows
Explorer although it works at the command line. Amazing the little things
you don't know.

2. Make sure that the ssh executable is in your path so that WinCVS can find
it.

3. I repeat, don't believe
https://sourceforge.net/docman/display_doc.php?docid=766&group_id=1 about
WinCVS.

4. Make sure that you use ssh to log into your shell account and CVS account
at least once prior to trying to use CVS.

ssh -l <user_name> shell.sourceforge.net
ssh -l <user_name> cvs.sourceforge.net

You might try logging in to shell1 as well. All the docs say shell but when
I take a look at my profile on SourceForge it says shell1.

Just for luck you should try the following but it shouldn't be needed.
ssh -l <user_name> squirrel-sql.sourceforge.net

5. Whenever you issue a CVS command you will have to login to CVS (unless
you've uploaded you keys and I haven't tried that yet). After you issue a
CVS command WinCVS will just sit there - forever. If you start alt tabbing
you'll see a command window right at the back with a title something like
SSH and its totally blank, no prompt. What its wanting you to do is key in
your SF password and press enter. Obvious isn't it?

If you have any problems go through all the doco (not just the Windows
stuff) at http://sourceforge.net/docman/?group_id=1.

If you still can't get it to work send a msg to the list and we'll all try
to help.

Worst case scenario until you get CVS working you can view CVS online at
http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/squirrel-sql/ and download
the distribution link I sent previously
http://squirrel-sql.sourceforge.net/alpha/. CVS has been updated since then
but its pretty close.

Good luck.

Col

The CVS respository has now been setup at SourceForge
http://sourceforge.net/cvs/?group_id=28383

The first alpha of Squirrel SQL Client 1.1 has finally been released. You
can get it from http://squirrel-sql.sourceforge.net/alpha/. The installation
file is an installer created by the Izpack Java installer, just execute it
from Java with the -jar option. The document plugins.html within the docs
directory of the distribution is the beginnings of a programming guide to
Squirrel.

How much of the plugin API is still to be written? Most of it. I'm going to
be driven by what you want as to what I implement next. Areas missing that I
am going to be addressing (in no particular order):

1. Data model for the SQL output.
2. Access to the objects tree for adding to both object types and objects.
3. A popup menu for the objects tree.
4. Allowing plugins to save/restore state to/from the SquirrelPreferences
object.
5. The ability to add tabs to the session window.
6. Allow the user to specify shortcut and accelerator keys for menu items.
This will get around the current problem of multiple plugins using the same
accelerator keys.
7. Allow the user to specify actions to be added to toolbars.
8. To make 6 and 7 work Actions need to be specified through XML config
files. Probably add actions to menus just through config files without
requiring Java code as it does at the moment.
9. Access to the SQL script before it is executed.
10. Tell me what else you want!!!
There are a number of plugins shipped with the distribution which are mainly
the beginnings of some plugins that I would like to see in Squirrel. These
are:

Database Information
--------------------
internal name: dbinfo
Description: Extend Squirrel by defining XML config files for various
databases. E.G. the method by which you retrieve the source for a stored
procedure is different between different databases but it is normally a
piece of SQL. Therefore you could have an XML file to specify this. E.G.

Status: 2% complete. I've done almost nothing on this.

Saved Queries
-------------
internal name: favs
Description: Allow the saving of queries in a manner similar to
Favourites/Bookmarks in a browser.

Status: 5% complete.

Look and Feel
-------------
internal name: laf
Description: Allows the user to select the current look and feel.
Status: 75% complete. This is basically a wrapper around the existing
Squirrel functionality. Still to implement is the specifying of default
fonts for various controls.

SQL Scripts
-----------
internal name: sqlscript
Description: This is a wrapper around some code supplied by Johan Compagner
which allows the saving/restoring of SQL scripts to/from text files.
Status 50% complete (maybe). Still to do is integrate Johans code for
generating structure/data scripts for tables.

=========================================

The Database Information and Saved Queries plugins are looking for somebody
to take them over. Just send a message to this list if you'd like to take
responsibility for them. I'm hoping that Johan will take over the SQL Script
plugin <hint/>.

These are a few ideas for other plugins that I think would be useful:

1. Table creation wizard.
2. Visual Query builder.
3. SQL results export utility (CSV, XML, text, HTML etc.)
4. Data maintenance. Spreadsheet or generating a maintenance panel on the
fly for a selected row.

If theres a plugin that you'd like to develop just send a message to the
list giving a quick description of the plugin and the internal name you'd
like to use. At some stage I'll put up a register of used internal names on
the web site.

Those of you who haven't sent me your SourceForge user names please do so so
that I can add you to the project. Theres no urgency on this as I still
haven't got CVS up yet. The next task!

Col