Thackston Russell wrote:
> Some comments...
> Glenn said,
>>Simply put, I won't need to locate the Primary Keys because I will
>>always use every column of the row in the WHERE clause, so any
>>that have been designated as Primary Keys will be included
> Updating of rows should not be done this way (in my opinion). We
> check for primary keys and, if supported, allow the user to
> record, matching on the primary key. If no primary keys are
> the table is not editable. This would encourage good database
> ensure reliable results. This seems to be the approach taken by
> commercial tools I have seen.
There are several reasons why I think we should let the user update
tables without this limitation:
- there may be tables that do not require primary keys
- as Colin has said elsewhere, many people do not identify primary keys
in their DBs
- the people using the tool may not be DBAs, and may not have the
authority/ability to add that info to the DB
I don't know about you, but tools that force me to follow a particular
picky policy drive me nuts. If we were to force this policy on our
users, I, for one, would not use Squirrel. I think we want to entice
users with the freedom to use our tool the way they want. Let it help
them, not get in their way.
Please let us know if there are circumstances in which the proposed
sequence of operations (including the checks for identical rows) will do
something unexpected to the database.
As for encouraging good DB design, you could always create a "Good
Database Design Hints" plugin, or even one that checks the DB against
some criteria and generates lists of suggested fixes.
> Glenn said,
>><snip> My suggestion is that when the user clicks
>>on a binary field that we pop up a small window containing the
>>a editable text field and a set of radio buttons that lets the user
>>view/edit the data as:
>> - bits ("10110011" - I would put spaces between each byte)
>> - hex ("B3")
>> - octal ("1 7 3" - I'm not sure of the best byte alignment here)
>> - ascii (i.e. as the ascii chars for those nybbles)
> I suggest when a user tries to edit a binary field, we pop up a
> prompts the user for the type of binary... bitmap (*.bmp), Word
> (*.doc), Rich text file (*.rtf), etc. Think plug-ins, user-defined
> etc. The user selects the data type; Squirrel then writes the file
> temp file and opens the file using a "default editor."
> For example...
> Bitmap (*.bmp) = C:\Program Files\Accessories\Paint.exe
> Word document (*.doc) = C:\Program Files\Office\Word.exe
> Rich Text file (*.rtf) = C:\Program
> Raw binary (*.bin) = C:\Program Files\pfe\pfe.exe
I believe that simple things should be easy to do. This means that if I
have a bit field and I want to flip one bit, I should be able to do that
directly in the Squirrel window, just as I do for strings and numbers,
without using an outside editor. Likewise, if I have a binary file that
contains some text and I want to change one of the characters from lower
to upper case, it would be nice to do that without resorting to an
external editor. External editors present the following issues:
- Their look and feel will be different from Squirrel, making it harder
for the user to switch back and forth between them.
- There is no such thing as a "default" editor for any given type. None
of the examples you gave would work on my machine (Linux). Moreover,
different people use different editors for the same types, such as
Picture It vs. Photoshop for .gif/.jpeg/.bmp.
There are an awful lot of data types out there. Creating an maintaining
the list of data types, their association with the editors, and managing
the different ways those editors are called in the different
environments seems like a lot of work, and that effort does not seem to
be focused on the main task of the Squirrel tool. If the user community
thinks this is a useful feature, it could be
However, your comments do make me think that we should be more flexible
than I had previously suggested. My thought now is that binary fields
(including BLOBs) should all be edited using the same window, and that
this window would have text fields and buttons providing for "Export to
file" and "Import from file" as well as the simple data view/edit text
window and controls.
> Glenn said,
>>I'd like to toss out another open issue here: Should we consider
>>an "Undo"/"Redo" mechanism to Squirrel? If so, then editing of the
>>would be one thing that should be tied into that mechanism.
> Let the user start and end sessions, maybe? They could, at any
> their changes by rolling back an open session.
> In fact, if we combine editing and sessions, it could work something
> 1. Open a table.
> 2. Start a session, which makes the table editable (checking for
> 3. Move around the table making changes, which are written to the
> not committed.
> 4. Commit or rollback the session (table is no longer editable).
> For a step-by-step undo feature, we could build a stack for SQL
> that mirror each change made (in step 3). Call it anti-SQL :)
> an undo would execute the top item on the stack.
Yes, I thought of that too. Unfortunately, there are people like me
that prefer to have their changes made to the DB immediately, and there
are others that want to be able to use the transaction scope in their
own way, which this might interfere with.
The "anti-SQL" suggestion sounds like a standard "undo" feature. I
think that is how we would need to implement such a thing.