Date: prev next · Thread: first prev next last
2016 Archives by date, by thread · List index


Hi :)
If you haven't already done so then posting this idea as a "feature
request" would be a really good way forwards.  Unfortunately not many devs
dare take on the challenge of working with Base.  So the next step might be
to promote it somewhere, preferably in a few different places.  This
mailing list is a good one.  Perhaps a MySql forum too.  Perhaps some sort
of crowd-funding or crowd sourcing place.  So, i think you are already
doing the right sorts of things.

Wrt trying to access a remote server, perhaps using ssh from a linux
command-line might be a way in?  Dealing with the server's sys.admin might
be a blocker, or rather finding a way of contacting them might be.
Regards from
Tom :)

On Wednesday, 27 January 2016, Heinrich Stoellinger <hc.stoellinger@aon.at>
wrote:

Hello,
I have been an avid user of LO/OO-Base for years, using it to connect to a
MySQL database for everyday work --- couldn't do without it. I am convinced
that a good connection to a DB-backend like MySQL/MariaDB is essential for
LO to be successful in a "real" business environment.
As I have mentioned in earlier messages to the list, I use JDBC to connect
to my remote DB-server as well as the native MySQL-connector for my local
test server.
Unfortunately I don't have access to the remote server and therefore cannot
change its idle-timeout, which is set at 60 seconds.
On my Linux-Mint system I also connect to the server via the command line
MySQL client. If - after going away for more than 60 seconds - I come back
to do more work, the client reports the timeout, but reconnects
automatically.
This is kind of acceptable, even in a business production environment.
Unfortunately the native connector does not support "autoreconnect". This
means that one would have to restart LO in case of a timeout (unacceptable
for "serious" work!) On the other hand, JDBC does allow the specification
of
"autoreconnect=true" as part of a connect string. However, unlike in the
case
of the MySQL command-line client, LO-Base doesn't simply reconnect
AUTOMATICALLY,
but displays a message such as "The last package sent to the server was x
seconds ago, the lase received packed was y seconds ago".
This means that whenever a timeout occurs, one has to confirm the wish to
reconnect - even though one has specified that one wants to do this in the
connect string when defining the DB-connection properties in the first
place!
I wonder how difficult it would be to implement such a REALLY automatic
reconnection...
Regards (and I appologise for the lengthy description...)
H. Stoellinger


--
Erstellt mit Operas revolutionärem E-Mail-Modul:
http://www.opera.com/mail/

--
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems?
http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be
deleted



-- 
To unsubscribe e-mail to: users+unsubscribe@global.libreoffice.org
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://listarchives.libreoffice.org/global/users/
All messages sent to this list will be publicly archived and cannot be deleted

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.