trying to change an ID-field, primary not set to auto-numbering change to autonumbering, rules to strange observations:
it looks, as if the sdbc is pointing to the wrong field and generates the wrong sql-statement.
pls have a look to attached screenshots
(LO 5.4.1/32 portable on W10/64 H)
Created attachment 136366 [details]
screenshot on SDBC-mismatch
Created attachment 136367 [details]
screenshot on SDBC-mismatch
Changed title to better reflect screenshot submissions
So your description is rather lacking in detailed information as you don't say how you created the table, or what additional attributes you have given to the different fields that one can see in the screenshot.
I have tried to reproduce using the default behaviour of LibreOffice using the manual way to create a new table in the GUI (not using the table creation wizard).
I took the defaults as suggested in the UI. For the INT column, I defined it as primary key with no auto(increment)value. Defined the remaining fields with the defaults provided by the LO UI, then saved.
Closed the ODB file, then closed LibreOffice.
Re-opened LibreOffice, then reloaded the ODB file, opened the table for editing and clicked on Autovalue = YES after selecting the priID field. When I attempt to resave the table, I get the following error message :
"The column "priID" could not be changed. Should the column instead be deleted and the new format appended ?"
Clicking on the "More" button shows the following error message:
SQL Status: IM001
Changing autoincrement property of existing column is not supported
If I then click on "Yes" in answer to the question to delete/new append, I see the following :
Error while saving the table design
*unsuccessful metadata update
*ALTER TABLE testprimkey failed
*SQL error code = -607
*Specified domain or source column SQL_LONG does not exist
ALTER TABLE "testprimkey" ADD "priID" SQL_LONG NOT NULL
This isn't the same error message as you have posted in your screenshot.
If you have done anything different than what I have described, please provide complete detailed step-by-step instructions here.
Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527
CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default;
Locale: fr-FR (fr_FR.UTF-8); Calc: group
Dear Bug Submitter,
This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.
For more information about our NEEDINFO policy please read the
wiki located here:
If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!
Dear Bug Submitter,
Please read this message in its entirety before proceeding.
Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):
a) Provide details of your system including your operating
system and the latest version of LibreOffice that you have
confirmed the bug to be present
b) Provide easy to reproduce steps – the simpler the better
c) Provide any test case(s) which will help us confirm the problem
d) Provide screenshots of the problem if you think it might help
e) Read all comments and provide any requested information
Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:
a) respond via email
b) update the version field in the bug or any of the other details
on the top section of our bug tracker
Alex Thurgood had no problem recreating it. Who cares if the error message is a bit different, the fact remains the code is broken in every build of Base right up to the first drop, yesterday, of the binaries for 6.2 Alpha0.
It shouldn't be up to the user to post an example for something this simple, and obviously wrong, in fact the fact it is in the wild for so long calls the entire QA process (and the commitment of TDF to produce a quality product) into question.
As for the difference in error messages - if anyone had tried for real that is really easy to understand.
With the HSQLdb engine data changes actually are written to DISC. // pause here for a second
OK, now here is what happened. Since the system had to DROP and then ADD the column back and since that can't be run as a single transaction the DROP column worked, the ADD column failed.
After clearing the error message box the Table Editor is now displaying a layout for the table that DOES NOT match the table on disc (for firebird it is the table in memory and here that is going to come in handy).
OK - so you try to close the table editor an guess what it prompts the user to save the table design again - if the user says yes a different error is triggered, it is the error reported by the OP in this issue.
If the ODB used HSQLdb that is it, the table has been altered by dropping the column and it must be added back by the user - in the case of firebird just don't save the file and the change is discarded, along with an other changes like data added to different tables and such (all would be lost).
Created attachment 142282 [details]
So here is a firebird embedded ODB for testing.
You have three tables, one view and a form.
The table EmployeesTasks will be for testing purposes here.
Tables Employees and Tasks share a dependency via the view View1 and you may not alter any of the related fields in Employees or Tasks while that view is in the schema.
How to reproduce the bug.
1 Download the attached ODB file.
2 Start Libreoffice if it is not running.
3 Open the file you downloaded in step 1
4 Go to the Tables section in the Base main window.
5 Select the table EmployeesTasks
6 Right click the mouse, on the table, and select edit.
7 When the table editor opens, select the primary key field 'ID'
8 Change the Auto Increment control from No to Yes
9 Click save changes
10 An error message informs you that the column must be dropped and added to the end of the table. Answer yes.
What actually happens:
An error message box opens again, during the final step of the change (adding the column to the end of the table) with a bad SQL statement. The command is trying to use a string constant of a data type descriptor in place of the actual data type name.
Clear the error message.
The table editor continues to show that a column ID exists, but it no longer does in the actual Table in the schema.
Close the table editor.
You are asked if you want to save the changes, if you say yes a new error message is displayed with the word 'GENERATED' in it - this is because Base used the table descriptor stored in Base, not from the schema, and is trying to alter a column that no longer exists.
Clear that and close the table editor again, this time do not save the saves when prompted.
Open the table itself and you will see that the ID field is gone.
Close the file, but do not save it and it is ready to test all over again.
It works. The ID field is moved to the end of the table, type integer and Auto Increment is true.
ps - if you find that when you reopen the file it is still marked as needing saving, remember that currently that file was not actually closed by the process. To make that stop you need to either save the file for explicitly or exit libreoffice and restart it
However, it seems the connection to the data engine is closed when the ODB file is closed in the UI (even if the file is not released), you know that because the table in the schema is again displayed with the ID field intact.
Changing from Windows to all platforms given that I can duplicate the OP report precisely using Linux.
I am on a Mac (High Sierra 10.13.6) and have run into a similar problem when using the embedded Firebird database (LO 184.108.40.206).
After a table has been saved, I am unable to change the primary key AutoValue from No to Yes. When I try to save a table after making this change, I get an error message:
The column "Field Name" could not be changed. Should the column instead be deleted and the new format appended?"
This is unfortunate, as there are certain ways of creating tables, such as dragging in a Calc file, which don't allow you to set the AutoValue when creating the table. In the embedded HSQLDB we were able to edit these fields after saving the tables.
Created attachment 144595 [details]
Embedded Firebird Database
A simple test database (Firebird embedded) I was using when I discovered this problem.
issue for FB-tables still exists in LO 220.127.116.11
besides that: When changing the field-name of the field formerly used as primary-key (expl: ID to ID-No) the table will become inaccessable: no records viewable + no further datarecords attachable (table-view with *-new does not come up)