Hello Ray, > I would have thought that the enforcement of referential integrity is > always the resposibility of the DBMS engine (the backend).
That is not about referential integrity, it's about uniquely identifying a certain row in a table. Imagine a table containing the following data: num | name -----+----------------- 1 | Some Name 1 | Some Name 2 | Some Other Name Now, when you in the GUI select the second record, and delete or update it - how should OOo dertermine which record is affected? There is *no* reliable way to detect this: - Describing the record by position does not work - a position is no reliable concept, the order in which records are returned by the database are not defined. - Describing the record by content does not work - both do have the same content - Deleting/Updating both rows is not what the user told us to do, so we can't If your table had a primary key or unique index (the fact that the latter suffices is often neglected in the discussion), this would prevent two rows with the same data, and allow to identify which row the user meant. If your driver would support so-called bookmarks (as it's the case for OOo's dBase implementation), then a row would be identifiable: Bookmarks are exactly this: a matter to uniquely identify a row. OOo handles bookmarks, but doesn't expose them to you as a user. In theory, OOo could accept the uncertainity, and still allow you to edit/update data when no PK/unique index/bookmarks are present. However, this could lead to unpredictable results, so we simply decided not to do it. Note that inserting new data also requires to uniquely identify data rows: Since the database backend (which OOo usually doesn't know about too much) can do own modifications to a newly inserted row, OOo must re-fetch the data after insertion. For this, again it's necessary to properly and uniquely identify *which* data record to re-fetch. > A popular competitive DBMS GUI, the MS Access 2002, does not impose > this extra requirement in its GUI design. Adding or updating rows in > tables without unique keys can be done in MS Access 2002, in > compliance with SQL standards. Is there any fundamental or > architectural reason why OO Base GUI could not achieve the same as MS > Access 2002? MSA itself, with it's own engine, supports bookmarks. When linking external tables, I am not sure if MSA also allows modifications if the database driver for the external table doesn't support bookmarks, and no PK/unique index is present. > 1. How to turn off the requirement of unique key or primary key, as > imposed in OO Base GUI, just before saving a newly designed table? You cannot. > Can I still ask for a way in future versions to turn off this behavior > in OO Base GUI? Sure, submit a request for enhancement in IssueZilla. There are several degrees how this could be "done". First, our HSQLDB integration could be teached to use bookmarks, which would make the problem much less obvious, since the default backend would not have it, then. Second, the restriction could be omitted upon user request - with all the consequences to data integrity. Not sure if this is a good solution. Third, OOo could try to apply some magic to identify the affected rows of some operation. This, however, is always limited, since you can always construct cases where you simply cannot guarantee the result of the operation, then. 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]
