Hello,
After changing the structure of a MySQL-table (deleting ONE column and
inserting another
column) I cannot access the table anymore through LO-Base. LO-Base still
keeps looking
for the old column.
Since everything works just fine when using the mysql-client
(Linux.Mint) through the
command-line, I assume that the problem might have to do with some kind
of cache that
persists across LO-restart and/or system boot. If this is so - can
anybody tell me where
such a cache might be stored under LO 4.2.5 or LO 4.3.1?
On the other hand, this only happens when using the JDBC-Connector.
However, I HAVE to use
this connector since the "wait_timeout" global value specification on
the server is too
low for "decent" work in my case and I cannot increase this value. The
native
MySQL-connector works fine, except that it doesn't have the possibility
to specify an
"auto-reconnect" parameter in the connection, so, again I cannot use it.
In MY case one
solution would be to have such a parameter also in the native connector
case...
Thanks a lot for any ideas
Heinrich
--
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
- [libreoffice-users] Problem with MySQL tables · Heinrich Stöllinger
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.