|
From: Colin B. <col...@te...> - 2002-10-09 03:56:10
|
Hi Russell, > 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 > columns > > that have been designated as Primary Keys will be included > > automatically. <snip> > > Updating of rows should not be done this way (in my opinion). We > shouldcheck for primary keys and, if supported, allow the user to > update the > record, matching on the primary key. If no primary keys are > defined, then > the table is not editable. This would encourage good database > design and > ensure reliable results. This seems to be the approach taken by most > commercial tools I have seen. The problem with encouraging good database design is that the people who can be encouraged are already doing it. The rest, well... One other advantage with the "every possible column in the where clause" approach is reducing the risk of losing changes to the database. If a Squirrel user has a row in "maintenance mode" and after they have retrieved the row aother program changes one of the columns then when the Squirrel user generates and executes the update statement it will fail (0 rows updated) as the row will not be found. Contrast this with just using the primary key where the first update will be silently lost. Also remember that people may be using Squirrel over databases that they didn't create and have no authority to change the structure. I wouldn't like the idea that we are saying that Squirrel will only work if your database is perfect. However it gets done I would suggest doing a "select count(*)" prior to the actual update just to check that only a single row gets updated. I'd hate for somebody to be screaming about Squirrel updating every row in a table when he only meant to update 1 row. > I suggest when a user tries to edit a binary field, we pop up a > window that > prompts the user for the type of binary... bitmap (*.bmp), Word > document(*.doc), Rich text file (*.rtf), etc. Think plug-ins, > user-defined list, > etc. The user selects the data type; Squirrel then writes the > file to a > 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 Files\OpenOffice\OpenOffice.exe > Raw binary (*.bin) = C:\Program Files\pfe\pfe.exe For the more complex data types (such as image files) this sounds good. I can see some issues coming up with file locking etc. but I'm sure they can be worked around. However I think that defaulting to "in place" editing would be simpler and would cater for most of what people want. Normally if I want to edit a binary column I just want to flip a couple of bits, a form of hex editing would be fine for me. This would mean that for most data maintenance people would't have to configure Squirrel to point to the various external programs. I've found that if you have to configure a option then most people won't use it, they want it to work "out of the box". > For a step-by-step undo feature, we could build a stack for SQL > statementsthat mirror each change made (in step 3). Call it anti- > SQL :) Triggering > an undo would execute the top item on the stack. I like the idea of a step by step undo but I'd suggest this as part of "phase 2". The standard commit/rollback could be used initially and the step by step undo added later. -- Colin Bell http://squirrel-sql.sf.net |
