Hi Regina, > You judge me right. Doing it the same way as Access is no argument to > me. Access has been developed about ten years ago. Shouldn't we better > in the meantime? Of cause we must help Access users, but not by > ?twisting (verbiegen) our product, but by leading them to the better > way. And I believe Access users are not too stupid to learn.
Well ... I don't really like to start this discussion here, again. Whether "clone MSO" or "do it your own way" is better has been discussed numerous times in different channels, and there are pros and cons for both approaches. In general: I agree with you (there's proof in multiple issues that I do not like the "do it like MS does it, just because MS does it so" attitude :). In particular: I don't think that in this case it should be the final argument against doing so ... Anyway, let's go over the particular items you raised: > (1) It has unwanted consequences concerning the embedded HSQL database: > Up to now views are readonly, so you cannot alter your data out of a > view, which on the other hand is possible out of a query. So you will > loose functionality unless you implement, to write a record out of the view. very good point. > (2) It is not necessary for the embedded HSQL database: > (2a) You can use views to nest your statements. But we'd still need the additional possibility to edit the underlying statement, to be "solution-compatible". > (2b) You can already use queries in queries by nested selects like > SELECT ... FROM (SELECT ...) ... As said in my response to Andrew, this misses a few of the advantages of queries-in-queries: Independent alterability, and re-usability. > (3) The way cannot be transfered to other database systems, because > (3a) they might not know views like older MySQL or flat tables. Which, for a first shot, would not hurt, IMO. When time comes for a second shot, nobody will use this old MySQL version anymore :) (and for flat tables, all other architectures won't work, too, since they don't know sub selects, anyway) > (3b) the user might not have the right to create a view, but has only > the read right and perhaps update right on the table. good point (already raised by Ocke after I published the spec draft) > (3c) Views are stored in the database system which might be on a server, > to which the user has no write access, but queries are stored in the > odb-file and therefore are possible for each user. That's the same as (3b), isn't it? For the moment (thanks so far!), I'll update the document with the concerns raised so far. At least (1) and (3b) sound pretty convincing to me that forcing queries to be views might not be the ultimate way. Thanks & Ciao Frank -- - Frank Schönheit, Software Engineer [EMAIL PROTECTED] - - Sun Microsystems http://www.sun.com/staroffice - - OpenOffice.org Database http://dba.openoffice.org - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
