Bug 112491 - SDBC-mismatch on alter field-properties in embedded Firebird database when editing primary key
Summary: SDBC-mismatch on alter field-properties in embedded Firebird database when ed...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Database-Firebird-Default
  Show dependency treegraph
Reported: 2017-09-19 11:31 UTC by mhonline
Modified: 2018-12-19 03:58 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

screenshot on SDBC-mismatch (102.20 KB, image/jpeg)
2017-09-19 11:33 UTC, mhonline
screenshot on SDBC-mismatch (98.07 KB, image/jpeg)
2017-09-19 11:33 UTC, mhonline
test ODB (13.82 KB, application/vnd.oasis.opendocument.database)
2018-05-25 21:30 UTC, Drew Jensen
Embedded Firebird Database (5.74 KB, application/vnd.oasis.opendocument.database)
2018-09-01 18:13 UTC, kam3don

Note You need to log in before you can comment on or make changes to this bug.
Description mhonline 2017-09-19 11:31:06 UTC
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)
Comment 1 mhonline 2017-09-19 11:33:14 UTC
Created attachment 136366 [details]
screenshot on SDBC-mismatch
Comment 2 mhonline 2017-09-19 11:33:54 UTC
Created attachment 136367 [details]
screenshot on SDBC-mismatch
Comment 3 Alex Thurgood 2017-09-21 07:23:34 UTC
Changed title to better reflect screenshot submissions
Comment 4 Alex Thurgood 2017-09-21 08:13:13 UTC
@mhonline :

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
firebird_sdbc error:
*unsuccessful metadata update
*ALTER TABLE testprimkey failed
*SQL error code = -607
*Invalid command
*Specified domain or source column SQL_LONG does not exist
caused by

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.

Tested on 
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
Comment 5 QA Administrators 2018-04-04 13:08:26 UTC Comment hidden (obsolete)
Comment 6 QA Administrators 2018-05-02 15:51:18 UTC Comment hidden (obsolete)
Comment 7 Drew Jensen 2018-05-25 21:20:03 UTC
Reopening this.  

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).
Comment 8 Drew Jensen 2018-05-25 21:30:06 UTC
Created attachment 142282 [details]
test ODB

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.
Comment 9 Drew Jensen 2018-05-25 21:40:10 UTC
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.

Expected results:
It works. The ID field is moved to the end of the table, type integer and Auto Increment is true.
Comment 10 Drew Jensen 2018-05-25 21:56:31 UTC
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.
Comment 11 Drew Jensen 2018-05-25 21:57:42 UTC
Changing from Windows to all platforms given that I can duplicate the OP report precisely using Linux.
Comment 12 kam3don 2018-09-01 18:10:55 UTC
I am on a Mac (High Sierra 10.13.6) and have run into a similar problem when using the embedded Firebird database (LO

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.
Comment 13 kam3don 2018-09-01 18:13:47 UTC
Created attachment 144595 [details]
Embedded Firebird Database

A simple test database (Firebird embedded) I was using when I discovered this problem.
Comment 14 mhonline 2018-11-20 23:54:57 UTC
additional info:

issue for FB-tables still exists in LO 

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)