Created attachment 117011 [details] screenshots of dialogs While changing a table name, Database alerted me that the table appears in a view (~query) and offers to change the name there as well. When I accept OK, it fails to make the change and returns to the alerting dialog. The only way out is to cancel, accomplishing nothing.
@Jim : please provide a sample ODB file containing the table and views so that we can test. Also please indicate whether you are using stock LibreOffice, or Collabora provided LibreOffice from the AppStore. Setting to NEEDINFO, pending requested information.
Created attachment 117034 [details] example database illustrating problem In Tables view, try changing the name of ClipSurvey to e.g. ClipSurvey_foo (using right-click on name of ClipSurvey, Rename menu item). You should get a complaint: "Table is referenced by view: TrainingSet1 in statement [ALTER TABLE "ClipSurvey" RENAME TO "ClipSurvey_foo"]. Click on OK. You should get a dialog titled Rename to, with a data field labeled Table Name, with the contents "ClipSurvey_foo". If you click on OK, you should get the "Table is referenced ..." alert again - at least I do. Only way out is to cancel on the Rename dialog (accomplishing nothing, except a graceful exit).
The message I see in LO4452 : dependent objects exist: PUBLIC."TrainingSet1" in statement [ALTER TABLE "ClipSurvey" RENAME TO "Clips"] Confirming that the "Rename to" dialog refuses to take the new value and throws error message again.
I'm guessing that this is unimplemented functionality, so this would probably turn out to be a RFE
That said, the UI shouldn't offer more than what it can actually do IMHO, so perhaps with dependent objects such as Views, we need to have a better error message and not display the rename dialog ?
(In reply to jimrussell98116 from comment #0) > While changing a table name, Database alerted me that the table appears in a > view (~query) and offers to change the name there as well. Not quite. The renaming failed, so it goes back to the dialog that failed, allowing to modify the request. This is still not in any way trying to do anything with the view. LibreOffice is not really aware of why the renaming failed; it might be e.g. because the name is already in use or invalid. In this case, going back to the dialog is a reasonable choice since choosing a new (free) name will lead to a successful renaming. In the case at hand, where there is a dependency, there is no renaming that can succeed, so indeed the redisplay of the dialog is rather pointless. Could LibreOffice be made aware of the reason the rename failed? I'm not sure. If the SQLSTATE (error code) given is detailed enough, then, yeah. But at first sight it does not look like it. More generally, I don't expect all (or many) databases to even be able to do such a "simultaneous rename"; in most databases, one would have to drop (delete) the view, rename the table and recreate the view. This is not completely impossible, but is rife with fragility, such as e.g. ~data loss if the process is interrupted or in case of error during the process, the need to put again the same privileges on the view after it is recreated, etc. For the "what if interrupted in the middle", a transaction would not always work; not all databases version DDL statements (Data Definition Language, statements touching to table/view/... structure, permissions, etc as opposed DML, Data Manipulation Language, statements touching only data). (In reply to Alex Thurgood from comment #5) > That said, the UI shouldn't offer more than what it can actually do IMHO, so > perhaps with dependent objects such as Views, we need to have a better error > message and not display the rename dialog ? I'm not opposed in principle to that, but I'm not sure LibreOffice has access to a reasonable API that gives dependencies to predict if a rename is possible or not. Maybe there is, not sure.