On 1 August 2016 at 21:49, Girvin Herr <girvin_herr@fastmail.com> wrote:
On 08/01/2016 11:35 AM, Jaroslaw Staniek wrote:
On 1 August 2016 at 00:16, Girvin Herr
<girvin_herr+gherr_lists@fastmail.com> wrote:
Ken,
One thing about Kexi. I looked at it a few weeks ago and discovered that
Kexi has a capability of reading Access database files to some degree.
However, it reads and converts the access database into its own internal
database. Kexi has no capability to interface to and use an external
database server (aka "Back End") such as Mariadb or MySQL, as LO Base does.
Hi,
If you mean ability to connect without generating any metadata as in
pure frontends, and being a SQL frontend, then yes. The internal
database is created on first use, however it still can be the server
database possibly running on the same server like the original one,
it's just not the same database.
I recommend https://en.wikipedia.org/wiki/Kexi#Features - 2.x supports
MySQL, PostgreSQL, xBase and MS SQL/Sybase backends (it does so
without limiting itself to capabilities of ODBC/JDBC).
KEXI 3 would be able to do open databases "in place", just not 3.0.
Still, it would not be called a db frontend however transmitting
unchecked/raw SQL strings back and forth; it would be still more a
different type of software: an integrated app creator / environment,
so a slightly more high-level tool.
Jaroslaw,
What I found back on July 4th (and today) is this snippet from the Kexi FAQ,
Q1.2:
http://kexi-project.org/wiki/wikiview/index.php@KexiFAQ.html
"- Currently you can not "open" (i.e. connect to) databases created outside
of Kexi. You can only import the tables and data. "
That tells me that databases other than Kexi can only be imported (converted
to Kexi format and maintained internal to Kexi, not Kexi maintaining the
server version). When Kexi states that they support databases like "MySQL,
PostgreSQL, xBase and MS SQL/Sybase", I must assume they mean that Kexi can
import and convert such databases, not connect to their server and maintain
the server versions. There is a big difference.
You are right, there's a difference. But there is no Kexi format.
Databases are imported back to any place you have access to, that can
be very the same server you already use.
To possibly clarify this a bit since we touche the topic of this
thread - the "compatibility" - I'd like to add:
- Just connecting to a database and not emplying any meta data would
mean forms, reports, scripts, etcetera, can't be saved. This is
because no server we're talking about has support for "CREATE FORM",
"CREATE REPORT" command, a standardised one or not. Kexi does, that's
the reason for having own extensions. Just like Base but please refer
to the next point.
- Kexi needs no additional database or XML files to store forms,
reports, etc. Commands like "CREATE FORM" are translated to native SQL
commands of your database of choice, on the fly.
- Based on the above, all data stored and raw structures are
accessible without exporting to other MySQL/PostgreSQL/MS SQL tools
and APIs. There's no what would be called a Kexi format, there's the
meta data. Of course forms are not visible to, say, MySQL because
MySQL has no form capabilities and is not designed for that. (Neither
Oracle has, Oracle Forms has, as an extension)
For example if we crafted a form or report running on top of table
"Customers (ID, name, surname)" and add column (age) to it in MySQL
Admin tool, change _won't_ be visible in the form, no matter what tool
we're using.
These above design choices were justified by these facts and that back
in 2004 some backends such SQLite 2 had no way to fully discover the
schema schema. As said before KEXI 3 would have the discussed behavior
a bit more liberal, benefiting from advancements in database backends.
Cheers
My Kexi research was precipitated by confirming that AOO 4.1.2 had a broken
Report Builder and it looked like it was not going to be fixed anytime soon.
This was a show-stopper for me. My Slackware 14.1 Linux comes with Kexi
2.7.4, so I naturally looked at it. I was searching for another Mariadb
client option to see what Kexi could do for me, since I was having problems
with LO 4.x+. When I discovered the above FAQ statement, it told me I could
not use Kexi in my application. I was not going to get "locked in" to
another integrated application like MS Access. It could be that at some
time in the future Kexi will have the connection capability that I require
and I may revisit it.
In case you're interested, I ended up using AOO 4.1.2 for documents, which
doesn't have the problems I am having with LO 4+, and LO 5.0.6 for my
databases, which has a working Report Builder (Kudos to the devs for fixing
the lines in reports not WYSIWYG problem).
Girvin
--
regards, Jaroslaw Staniek
KDE:
: A world-wide network of software engineers, artists, writers, translators
: and facilitators committed to Free Software development - http://kde.org
Calligra Suite:
: A graphic art and office suite - http://calligra.org
Kexi:
: A visual database apps builder - http://calligra.org/kexi
Qt Certified Specialist:
: http://www.linkedin.com/in/jstaniek
--
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
(message not available)
[libreoffice-users] Re: Compatibility of LO Base with Access databases · Ken Springer
[libreoffice-users] Re: Compatibility of LO Base with Access databases · Andreas Säger
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.