Sorry I've been flat out at work and am only now catching up with my emails.
> In Microsoft SQL Server's Query Manager, I can select one or many database
> objects, hit ctrl-c, and have the schema for the table(s) (text, natch) in
> my clipboard. AWFULLY handy. Worth pursuing in SQuirreL?
The SQL scripts plugin does something similar, it generates CREATE TABLE
statements and places them in the SQL entry area. By schema do you mean
CREATE TABLE statements or something else?
On the other stuff it seems that you'll need some changes in the SQuirreL
- New Session - setting continue/abort on error. When executing multiple
SQL statments, if one fails should the next ones be executed?
- A way for plugins to interrogate and/or modify the _complete_ SQL script
prior to it being split and executed.
I can do those once I've got the first beta of 1.2 out.
PS I'm away for the next few days so I'll be appearing to ignore emails
From: Ruffin Bailey [mailto:Ruffin.Bailey@...]
Sent: Wednesday, 4 June 2003 1:02
Subject: [Squirrel-sql-develop] Get table schema & RE: Auto DROP
A "feature request/can I do this", and a fwd of a message that hasn't come
through just yet (sent May 20th; sorry if it "deluges" later).
In Microsoft SQL Server's Query Manager, I can select one or many database
objects, hit ctrl-c, and have the schema for the table(s) (text, natch) in
my clipboard. AWFULLY handy. Worth pursuing in SQuirreL?
Second bit is my reply for the Auto DROP function -- basically just looking
to use on VIEWs, so should be relatively safe. Adding a pref for tables too
is a good idea. Email quoted below.
Ruffin Bailey wrote on Tuesday, May 20, 2003 10:58 AM:
> [Another possibility would be to look at the SQL prior to it being
> and if there is a CREATE TABLE command then execute a DROP command
> The problem of course is that this would throw an error if
> the table/view/whatever object *didn't* exist before the
> statement the user created executed. Squ'l could silently
> bitbucket the error thrown by the unnecessary drop statement,
> I suppose, and though it's somewhat kludgey that's a valid route, I think.
> [There is an API
> that allows you to look at SQL before it is executed and if necessary
> modify it.
> In your case you'd probably want to look at the SQL _before_ its split
> the three statements and then add a DROP TABLE to the start.]
> That sounds like a good way of doing it, again if you could bitbucket any
> errors there.
> [Because I'm a very nervous person I would want this behaviour to be
> configurable. I.E. have an application setting something like 'Auto drop
> tables before create true/false" with the default being false so that the
> user has to change it to true if they want this behaviour.]
> That's a good idea -- I normally wish I had this feature when
> I'm making reports and optimizing views and sprocs, in which
> case an accidental drop isn't such a big deal. Guess the
> best way to go is to set up different settings for each
> object type. Might set up the plugin to drop views by
> default, but you'd have to manually change settings for other types. ??
> I like the way you started using single quotes for your
> quote, above. Wonder where that came from? ;^)
> Thanks for your help,
> Ruffin Bailey
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
Squirrel-sql-develop mailing list