Created attachment 87131 [details] starting point for STR This reminds me of a bug report I have seen recently, but I am unable to find it. Redirection welcome. STR: ( 1) Open the attached example.odb. ( 2) If LibreOffice issues a security warning about macros in the document, click <Disable Macros>. ( 3) Open table Table1. Program presents Table Data View showing three rows of data; the Save icon in the toolbar is greyed out. ( 4) In the empty row of the data grid, type 4<tab>four. The Save icon in the toolbar is enabled. ( 5) Type <tab>. Cursor moves in a new empty row, and the Save icon in the toolbar is greyed out. ( 6) Close Table Data View. Program returns focus to example.odb; the save icon in the toolbar is greyed out. ( 7) Close example.odb. Program display Start Center. ( 8) From the list of recently used files, open example.odb. ( 9) If LibreOffice issues a security warning about macros in the document, click <Disable Macros>. (10) Open table Table1. Program action expected: to display Table Data View with four rows of data. Program action observed: to display Table Data View with three rows of data. This observation comes from master commit 95e95e0, fetched 2013-09-19, configured with --enable-option-checking=fatal --enable-dbgutil --enable-crashdump --without-system-postgresql --without-myspell-dicts --with-extra-buildid --without-doxygen --with-external-tar=/home/terry/lo_hacking/git/src built on ubuntu-natty (11.04) 32-bit, executing on ubuntu-quantal (12.10) 64-bit.
Reproducible. Win7x64 Ultimate Version: 4.2.0.0.alpha0+ Build ID: 0d0d3a0540dad2d0f417e21df1183dfc33964357 TinderBox: Win-x86@39, Branch:master, Time: 2013-09-30_23:58:26
I'd be interested to know what happens with other databases. In the case of HSQLDB all changes are stored directly to file due to the way the HSQLDB/.odb interaction works (and apparently HSQLDB lacks proper transaction support) -- with external databases I suspect nothing should happen until a transaction commited (as is the case with Firebird). I suspect the problem is simply that "Save" is erronously not enabled when we add a row, i.e. we simply have to set the Modified flag when inserting data too (as happens for most other operations). (This might be a historical artifact of Base having been tested mainly with HSQLDB?) That would however mean that in Firebird data is only ever commited to the .odb file with a "Save", whereas HSQLDB always has its data stored immediately, i.e. there'd be a significant difference between the operation of the two dbs in practice.
(In reply to comment #2) > I suspect the problem is simply that "Save" is erronously not enabled when > we add a row, i.e. we simply have to set the Modified flag when inserting > data too (as happens for most other operations). (This might be a historical > artifact of Base having been tested mainly with HSQLDB?) Yes, there is that horrendous hack that an embedded HSQLDB does a "save data in the ODB" on commit, which probably led to disabling the save button. With Firebird, which I understand saves the data on an explicit "save the ODB" action, the save button should indeed be activated on insert, modify, delete (any data change). > That would however mean that in Firebird data is only ever commited to the > .odb file with a "Save", whereas HSQLDB always has its data stored > immediately, i.e. there'd be a significant difference between the operation > of the two dbs in practice. I though we already had decided they would have this difference, *but* taking care that autosaves / backup saves have fresh data (not the same data as the last save), so as to have some level of crash tolerance.
Indeed, it does come down to "Save" being disabled. If you do something else in the file to enable Save, then you can Save; and this captures added rows. For comparison, if you Save from the Table Data View while its Save icon is enabled (e.g., step 4 of the original STR), it does nothing that I can see. Terry.
Changing summary to more closely reflect the cause of the problem. For the convenience of anybody searching for the symptom that I reported, the original summary was: cannot add row to table in embedded Firebird db
(In reply to comment #5) > Changing summary to more closely reflect the cause of the problem. For the > convenience of anybody searching for the symptom that I reported, the > original summary was: > > cannot add row to table in embedded Firebird db Have tested it with Build ID: b1caf176a44b6979d2e0ea47f495a3dacf86e197 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2013-10-12_06:04:49 Why did you change the summary. I have created a database with only one table. Could input new rows, could press save during input, could move through the rows, could close the table, could reopen the table and see the rows - but when I close the database and reopen it all data were lost. The database loose not some, but all changes.
(In reply to comment #6) > Why did you change the summary. > [snip] > The database loose not some, but all changes. If you do an action that the program *does* recognize as changing the should-be-saved .odb file, then the program enables the Save option and upon closing the file prompts you if you have not saved your changes. If you save your changes, the data changes are saved too. For example, if you create a query and save it from the query creation window, the program recognizes a change impacting the .odb. So, the program does not always lose all added rows. Creation of a table (IIRC) is another case where the program does not realize that the .odb is impacted. So the program loses some other changes beside added or changed rows. It is hard to write all this in one line. Terry.
So, looking at things, it looks like one way of attacking the problem is simply sprinkling plenty of: ::dbaccess::notifyDataSourceModified(m_xParent,sal_True); wherever we've modified any data in the database within dbaccess. (See https://gerrit.libreoffice.org/#/c/6620/ for an example which fixes the the problem for inserting data into a single table.) However this would mark the document as changed even if changing data in an external database -- hence I think it might make more sense to instead notify the document that it has changed from the database driver itself, and/or test that we are working with an embedded db before marking the document as changed? (I'm currently still looking at the different options for doing this.)
> However this would mark the document as changed even if changing data in an > external database -- hence I think it might make more sense to instead > notify the document that it has changed from the database driver itself, > and/or test that we are working with an embedded db before marking the > document as changed? (I'm currently still looking at the different options > for doing this.) This does in fact seem to be the best solution -- patch in https://gerrit.libreoffice.org/#/c/6621/ , however this only fixes things for editing existing tables (and deleting tables), inserting a new table still doesn't result in the save button being enabled.
Andrzej J.R. Hunt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=acef4b26879f6f8d80c26f6d2ee80667cb6ed388 fdo#70144 Mark database document as modified when data inserted in firebird. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The problem is fixed in my debug build of master commit 3d7662, fetched 2013-11-19.
Andrzej J.R. Hunt committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=56d4f4b7b97eaf212a3bc6bdb1da767106e7224a fdo#70144 Don't reset Document's modified flag when inserting new table. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Andrzej J.R. Hunt committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c6e36556c14612aa1eaf976efc10db6c88e23fb0&h=libreoffice-4-2 fdo#70144 Don't reset Document's modified flag when inserting new table. It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.