Apache OpenOffice (AOO) Bugzilla – Issue 59584
Can't access table after trying to change a field name
Last modified: 2006-05-31 14:29:06 UTC
Hi, Step to reproduce . create a new database . create a new table with only one field 'ch1', . add a primary key to that field . save the table as 'table1' . create a view of this table . add 'table1' in the view . add 'ch1' by double click . save it as 'view1' . right click on 'table1' choose Modify . change 'ch1' by 'ch2' and try to save it . an error message appear : Column not found... . close the table without saving it . close the database file . open it again, click on the table tab, you've got an error message and can't access the table or the view I'm joing the database file showing the error message : Statut SQL: S1000 Code d'erreur: -78 error in script file line: 4 Column not found: ch1 in statement [ SELECT "ch1" FROM "Table1" "Table1"] Kind regards - Sophie
Created attachment 32600 [details] Base file with corrupted table
I've reset the component to Database access and set P2 coz data loss. alex
reassigning to fs
for completeness: The problem does not depend on ch1 being the primary key. If you let OOo add another primary key automatically (upon saving the table), the problem also occurs, you only save the error message when renaming ch1 to ch2.
targeting to 2.0.2. Sorry, 2.0 is out. 2.0.1 might be an option, but before we do this, I want to have the decision to really block 2.0.1 for this.
fs->oj: Please work with Fred on solving this.
fs->oj: I checked in Fred's patch (in CWS dba202d). This prevents the data loss insofar as now the column name cannot be changed anymore. However, now the table design asks the user whether the primary key should be deleted, of which ch1 is a part. This is somewhat strange, isn't it? Shouldn't we tell something like "the column could not be changed, should it be deleted/re-created?"?
Quote "This prevents the data loss insofar as now the column name cannot be changed anymore." Are you saying that this patch will check if the column you are about to rename is used by a view, and if so disallow the change? Quote "Shouldn't we tell something like "the column could not be changed, should it be deleted/re-created?"?" This ties in with the above question. If the column can not be renamed because it is referenced by the view, then the user should not be able to drop it either. In fact in 2.0.1 that is exactly the behavior, neither a column in, nor the table itself can be dropped while the view exists.
Fixed in cws dba202d
> Are you saying that this patch will check if the column you are about to rename > is used by a view, and if so disallow the change? Yes > If the column can not be renamed because it is referenced by the view, then the user > should not be able to drop it either. In fact in 2.0.1 that is exactly the behavior, neither > column in, nor the table itself can be dropped while the view exists. The least invasive fix we can do (and only this kind of fix is acceptable for 2.0.x, for stability reasons) will continue to use the fallback to delete/re-create columns which cannot be modified. Of course this does not make sense in this particular case, since deletion will also fail, as you outlined. But correctly determining this special case, and reacting appropriately, is out of scope for 2.0.x.
Please verify. Thanks. re-open issue and reassign to msc@openoffice.org
.
verified in cws dba202d
Hi, this is fixed in the current master. The current master is available at http://download.openoffice.org/680/index.html I close this issue now. Bye Marc