On Windows XP pro Sp3 and Windows 7 pro 64, when several spreadsheets documents are opened, Calc will stop responding when closing one. Similar with bug 43614, but on LO 5.0.1. Does not happen everytime, but very often on some computers. May be a software conflict ?
Had three spreadsheets open. Closed one and no problems appeared. Crazy bugs call for crazy solutions: https://wiki.documentfoundation.org/UserProfile#Resolving_corruption_in_the_user_profile Win 7 Pro 64-bit, Version: 5.0.1.2 (32-bit) Build ID: 81898c9f5c0d43f3473ba111d7b351050be20261 Locale: fi-FI (fi_FI)
We often have 6 or 7 spreadsheets opened. Most documents are stored on a NAS (LAN Gigabit). And the problem does not happen everytime and quickly. It mostly happens late in the afternoon, when closing everything.
Hi there! I recognized a similar Problem. I have a Base-Database, and i create a writer-document with a macro and a query. The database is locally stored on my PC, the writer-doc should be stored on a fileserver, mapped on a network-drive in win7pro. In my script is a test, wheter the store-location exists, after creating a uno-service for my paths (to store it alternatively on my local machine, if the network is down). [code] Path = createunoservice("com.sun.star.util.PathSettings") sDrive="Y:/" 'sDrive=ConvertFromUrl(Path.Work & getPathSeparator()) wait(200) 'msgbox "TEST vor" If ismissing(sPath) then sPath = sDrive & "MMB\allgemeine Korrespondenz" End If 'msgbox "TEST mitte" wait(200) If not FileExists(sPath) Then On Error Resume Next Mkdir(sPath) If not FileExists(sPath) Then sPath = Path.work End If End If wait(200) [/code] Every second time, the whole LO freezes. So i put into the 3 "wait"-commands. I've tested, i need all three... On LO4.5 100ms are sufficient, on LO5.0.2.2 i need 200ms to wait for. The same is at the end of the macro, when i save the file. Freezing without wait, no freeze, including the wait. I don't know, why i need the first wait-command. In my path-variables is no network-drive included. Maybe LO asks all drives on creating the path-variable with the uno-service, and there is the same unclear result-state as on the "FileExists"-function Think, this could be the same problem, as described in the bug. greez jakob
Still happening with 5.1.1 (stable will be out this week)?
I can't confirm anymore. Our customer had too much problems with LO and migrated all 15 computers to MS-office. Sorry.
(In reply to Jakobus Schürz from comment #3) > > I don't know, why i need the first wait-command. In my path-variables is no > network-drive included. Maybe LO asks all drives on creating the > path-variable with the uno-service, and there is the same unclear > result-state as on the "FileExists"-function > With Win, I have seen that when a mapped network-drive it's not available, and it is on some path or link, LO takes a lot of time to do some operations, like opening.
Windows 10 education 64, LO Version: 5.3.5.2 works fine. Many spreadsheets opened and when I closed one, didn't faced any problem
(In reply to halima from comment #7) > Windows 10 education 64, > LO Version: 5.3.5.2 > > works fine. Many spreadsheets opened and when I closed one, didn't faced any > problem If it works fine, you don't change status to NEW.
Sorry it was by mistake. I tried with a new version and could not reproduce it LO version 5.4.0.3 (x64)
Dear reporter, is this issue still reproducible in the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
(In reply to Xisco Faulí from comment #10) > Dear reporter, > is this issue still reproducible in the latest version of LibreOffice from > https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
As stated on 2016-03-03, we stopped using LO when access to NAS documents was needed. So I can't confirm the bug.
(In reply to jmgigandet from comment #12) > As stated on 2016-03-03, we stopped using LO when access to NAS documents > was needed. > So I can't confirm the bug. Closing, then.