<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Deleting the source CSV file of an Address List should delete it from data sources" href="https://bugs.documentfoundation.org/show_bug.cgi?id=125331#c6">Comment # 6</a> on <a class="bz_bug_link bz_status_UNCONFIRMED " title="UNCONFIRMED - Deleting the source CSV file of an Address List should delete it from data sources" href="https://bugs.documentfoundation.org/show_bug.cgi?id=125331">bug 125331</a> from <a class="email" href="mailto:lionel@mamane.lu" title="Lionel Elie Mamane <lionel@mamane.lu>"> Lionel Elie Mamane</a> <pre>(In reply to Heiko Tietze from <a href="show_bug.cgi?id=125331#c5">comment #5</a>) > (In reply to Lionel Elie Mamane from <a href="show_bug.cgi?id=125331#c4">comment #4</a>) > > I have no simple idea to enhance it. > > What do you think about my idea to gray-out those entries where the data is > (temporarily) not available? By data, you mean the actual data, not the .odb file. How do you determine that? You can't just try to connect: - can take network requests, time (large list), consume client licence spot on SQL server, ... - you may be missing a password; you will not ask the password of all entries(!). How will you reliably determine if the connection failed You want to limit it to non-network requests? You will still need to open each .odb file, see what it connects to (embedded data? network database? another data file?) and make a decision. Also not good for performance, a file can also be on a slow NAS / network filesystem over a VPN over slow Internet, ... If you mean checking whether the .odb file is reachable, that can work, and I would not oppose the patch. Not sure users will understand the difference between the odb and the data, but <shrug></pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>