When you have a form table linked to a table in a datasource, with multiple columns in the form table, if you have the property window open as you are switching between columns, libreoffice will close without warning. Another bug that I unfortunately came across, is that the recovery data isn't always the latest data. As I was experiencing this crash repeatedly, I began to save my work every few steps. But when Libre Office recovers, it recovers an old set of data, not the most recently saved data. So even though I was saving every few steps, the recovered data was from 30+ minutes ago, so I lost 30+ minutes of work.
About first bug, could you try with 3.5.1 version with a brand new LO profile ? (first with your current file and if reproduced with a brand new file) Could you attach the file to the bugtracker ? It helps to reproduce more quickly the problem. About the other bug, if still reproduced with 3.5.1 with same advice as first bug, could you please file another bug ? (this url https://www.libreoffice.org/get-help/bug/ is a very good guide to fill effectively a bugtracker)
(In reply to comment #0) > Another bug that I unfortunately came across, is that the recovery data isn't > always the latest data. As I was experiencing this crash repeatedly, I began > to save my work every few steps. But when Libre Office recovers, it recovers > an old set of data, not the most recently saved data. So even though I was > saving every few steps, the recovered data was from 30+ minutes ago, so I lost > 30+ minutes of work. This is not new. Base has forever suffered from unsynchronised data recovery on crashing. From what I know of the process, only some of the table data is loaded into RAM, the rest is only pulled in, as and when needed. The recovery mechanism, however, which defaults to every 15 minutes, will only pull in the latest state of what is in /tmp. If that doesn't happen to include your changes made to other parts of the table or the ODB file, which may be floating around in memory waiting to be written to the underlying db (shutdown compact), you are out of luck. Of course, I may have misunderstood the whole "streaming a db in memory is a good idea" sort of thing. Embedded HSQLDB in a ODB file is an accident waiting to happen. There are ways to make your data safer, even with HSQLDB. Alex
With regards to the first bug, I haven't been able to consistently reproduce this bug. It has happened once since I updated to 3.5.1, but I'm unable to reproduce it. With regards to the second bug, this makes sense. Thanks. I'm actually attaching to a PostgreSQL db through JDBC, so I'm not losing data. I was referring to the changes on forms (writer documents) used to add/modify data in an existing db. Nothing worse than losing a half hour of work when you're on a deadline. Especially when you thought you were saving your work. Seems like it would make sense to update the auto recovery data when a document is saved.
Hi pfreeman99, what ist your opinion now: bug od no bug? Are you using the latest LO-Version 3.5.5?
(In reply to comment #4) > Hi pfreeman99, > > what ist your opinion now: bug od no bug? > Are you using the latest LO-Version 3.5.5? I'm using 3.5.5. It seems that the column selection in a table control is much more stable now. I haven't been using it as much after 3.5.4, but prior to this, it seems like column selection in a table control was very spotty. Occasionally if you opened the properties window while a column was selected, the column would remain highlighted but you wouldn't have access to the properties, even if you tried reselecting the column. You would have to go out of edit mode and back in to reset the column. Sometimes, it would crash base all together. I haven't been able to get it to do this lately, so something must have been fixed. Thanks.
Created attachment 64785 [details] Image with two column controls selected
I've actually just been able to reproduce where you aren't able to access a column's properties unless you exit the design mode. Using 3.5.5. It only appears to happen if you get an error (in my case an SQL error) as you go from design mode to view mode. 1. Select a column in a table control. 2. Go into View Mode (Turn off Design Mode). 3. Get Error. 4. Originally selected column is again highlighted, but you don't have access to it. You can select a different column and get access to those properties, but you're never able to reselect the original column. I've attached a screen shot with 2 columns highlighted. The column that was selected before I went into view mode, and then the column I selected after I left view mode.
Any update with a recent LO version (last one is 4.2.5)?
I couldn't reproduce the buggy behavior, describesd in comment 7. Have tested it here with OpenSUSE 12.3, 64bit rpm Linux. No problems to switch from design-mode on to design-mode of, when a field is selected and properties of the field where shown. Have tested it with LO 3.3.4 and some other (old) versions, also with LO 4.2.7.2. If it's a bug it must be a special Windows-bug.
Following last comment, let's put this one to WFM. pfreeman99: if you can reproduce this with a recent LO version (last stable one is 4.3.3), don't hesitate to reopen this tracker.
Yes. I think that is exactly what OP was asking for. Thanks for taking this on.
thanks https://ometv.onl https://chatroulette.top https://omegle.wtf https://bazoocam.cam