|
From: Colin B. <col...@te...> - 2002-11-20 22:54:04
|
Hi, > wanted to edit it. This can be done, but it would be simpler to > implement and simpler for the user if there was only one representation. > An easy way to do this is to remove the options in the Session > Properties and always display the data in the String form. So my first > set of questions are: > > - Does anyone prefer to see "<Binary>" in the field instead of the > actual data, and if so, why? > - How upset would you be if we removed the options and set it so > that you always see the actual data? The only reason that binary, varbinary and longvarbinary are options is because of an incompatibility with a particular driver/sql server. If a binary column was returned in a resultset even calling .next() on the result set would cause the driver to spit the dummy. Unfortunately I can't remember the driver/dbms involved and I lost all my email a little while ago when I lost my harddrive. Blob/Clob is there for performance reasons. If you're reading large blobs performance slows up. We really need a decent data model behind the viewing of the data. I.E. you should be able to retrieve the data type for a column from IDataSetModel, whether it was fully, partially or not retrieved (E.G. <binary>) etc. and only make the column editable if the data was fully retrieved. > > The second issue is this. If I am editing a nullable VARCHAR field and > > I remove all of the characters from the visible display and save it, > > does that mean: > > - set the field to null, or > > - put a zero-length string into the table? > > My suggestion is that when you remove all the characters, that means a > > zero-length string, and if you hit the delete key again, the field > > toggles between a zero-length string an a <null>. Would that work for you? > > In 15+ years of building and supporting relational databases, I have yet to > come across an application where a zero-length string is a useful data value > (just lucky I guess?). I would prefer that an empty string be converted to a > null value. If you do implement the proposed behaviour, would it be possible > to have an on/off switch as part of the session properties (i.e. setting the > option to 'on' would allow zero length strings, setting the option 'off' would > convert zero length strings to null values). I've come across a number of applications where both nulls and empty strings are used and as Maury says theres nothing useful about it. In fact it has been a source of bugs on more than one occasion. I like the idea of a session setting, "Treat zero length strings as null" and I think it would be the simplest to implement. If you do go with the toggling (and I'm sure somebody will want it) just make sure that its configurable. >> That raises another thought, which is how to deal with that "Oh #*@%&" >> moment just after you have accidentially touched a field that you did >> not want to change and you don't remember how it looked originally. Ome >> way might be to have a right-click menu item for "Restore original Cell >> contents", but that may be hard to implement. Another approach could be >> that when you delete everything from the cell and hit the delete key >> again, the original contents are restored. With a nullable field, this >> would cycle through the possibilities as follows: >> - delete the data in the cell => the data is zero-length >> - hitting delete key again => <Null> >> - hitting delete key again => original contents of the field >> Would this be ok? > >Hitting delete and seeing the original field contents restored would be >confusing and nonstandard behavior. I think an undo mechanism is called for >here. I assume that, now that you're going to make the contents display >editable, you'll be adding an Edit menu with Cut, Copy, and Paste commands. >How about including an Undo command that undoes the last edit? > >If there are operations that you don't want to support Undo for, then you >could have Undo grayed out after the user performs one of those operations. >For example, in MS Access when the user deletes a row, Access pops up a >dialog warning that the operation cannot be undone. I like the undo option, toggling the data with delete would be confusing. -- Colin Bell http://squirrel-sql.sf.net |
