Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-05 Thread Girvin Herr
dBase files are plain text, but they have a specific format, which 
varies with version (feature add-ins).  I did some research on the file 
format when I was trying to decide how I wanted to approach resurrecting 
my files. Another option is to use the old dBase 1.x under dosemu under 
Linux.  Actually, that may be the easiest way to do it, but maybe not 
the long-lasting correct way.


Girvin


On 08/04/2016 09:57 PM, Walther Koehler wrote:

My doctors office uses a dBase based system for administration, keeping
patient records and so on. It has integrated LO for many purposes, i.e.
medical letters. As I was told, reading those dbf files using scripts is easy
(dbf_dump), modifying dbf files from outside the program however tedious,
they use LO base for that purpose. Unfortunately, the SQL commands for dBase
are limited.

Walther




--
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-05 Thread Walther Koehler
My doctors office uses a dBase based system for administration, keeping 
patient records and so on. It has integrated LO for many purposes, i.e. 
medical letters. As I was told, reading those dbf files using scripts is easy 
(dbf_dump), modifying dbf files from outside the program however tedious, 
they use LO base for that purpose. Unfortunately, the SQL commands for dBase 
are limited.

Walther

 etc.Am Donnerstag, 4. August 2016 schrieb Girvin Herr:
> On 08/04/2016 09:16 AM, toki wrote:
> > On 02/08/2016 16:39, Ken Springer wrote:
> >>> Now that you mentioned dBase, you may, or may not, be aware that LO has
> >>> a dBase option.  But a limitation to it that I found is that older
> >>
> >> I didn't know this, but must admit dBase is probably not the best
> >> answer.
> >
> > For most individuals, dBase3 is adequate. Perhaps a little slow, but
> > with current hardware, not spectacularly so. However, the major
> > stumbling block is that there is even less LibO documentation for it,
> > than there is for Base.
> >
> > jonathon
>
> I used dBase in the 80s and I must assume that since it still seems to
> have a demand, that users are still out there and happy with it.  It did
> have some nice features, such as the programming capability, which is
> why I tried to import my files into LO rather than reinvent the wheel.
> I suspect most of the users are "on the other side of the pond", since I
> rarely hear of dBase users here in the US.  Then again, Fortran is still
> active too.  It takes a long time for that flywheel to coast to a stop.
>
> Girvin



-- 
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-04 Thread Girvin Herr

On 08/04/2016 09:16 AM, toki wrote:

On 02/08/2016 16:39, Ken Springer wrote:

Now that you mentioned dBase, you may, or may not, be aware that LO has
a dBase option.  But a limitation to it that I found is that older

I didn't know this, but must admit dBase is probably not the best answer.

For most individuals, dBase3 is adequate. Perhaps a little slow, but
with current hardware, not spectacularly so. However, the major
stumbling block is that there is even less LibO documentation for it,
than there is for Base.

jonathon


I used dBase in the 80s and I must assume that since it still seems to 
have a demand, that users are still out there and happy with it.  It did 
have some nice features, such as the programming capability, which is 
why I tried to import my files into LO rather than reinvent the wheel.  
I suspect most of the users are "on the other side of the pond", since I 
rarely hear of dBase users here in the US.  Then again, Fortran is still 
active too.  It takes a long time for that flywheel to coast to a stop.


Girvin



--
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-04 Thread toki
On 02/08/2016 16:39, Ken Springer wrote:
>> Now that you mentioned dBase, you may, or may not, be aware that LO has
>> a dBase option.  But a limitation to it that I found is that older

> I didn't know this, but must admit dBase is probably not the best answer.

For most individuals, dBase3 is adequate. Perhaps a little slow, but
with current hardware, not spectacularly so. However, the major
stumbling block is that there is even less LibO documentation for it,
than there is for Base.

jonathon


-- 
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-03 Thread Heinrich Stoellinger

Hello,
I agree full-heartedly with Alex, but then I have been working with relational 
DBs
ever since my days at IBM (DB2), where I specialised on databases for a while. 
In fact
I happened to get to know one of the fathers of that technology - Chris Date. I 
have
been using OO and LO with a MySQL-backend for at least 10 years since switching 
from
Lotus (Dbase-based). Except for a couple of snags with the MySQL-connectors 
(native,
Java and ODBC) I have never had any problems worth mentioning, and - of course 
- I do
back up my DB. But then, I probably am not the average "end-user"-oriented 
bloke, even
though I would not call myself a DB-specialist any more. I use LO and MySQL for 
the
administrative side of a wind band, working "natively" with the underlying 
tables and
using a number of views based on joined tables for reporting. Using Drupal as 
the framework
for the homepage of the band (www.rainermusik.at) I also have integrated some 
of those
MySQL-views with Drupal.
I never really went into using LO-forms or Basic macros because I feel that one 
should take
the effort to use a framework such as Symfony for building more involved 
applications,
using an object-oriented approach, with something like Doctrine as a link 
between the
objects/methods of the application and the MySQL DB.
Regards from sunny Salzburg
Heinz


On Wed, 03 Aug 2016 12:15:19 +0200, Alexander Thurgood 
 wrote:


Le 02/08/2016 à 00:23, Ian Whitfield a écrit :

Hi Ian,




*Re: The LO Base discussion* - just my "Penny's Worth"!!!




The only way I got any (sort of results) was by using MySQL as the
backend but it took a couple of months to get it working and after a few
months even that crashed on me. I recently had to re-build my computer
after a hardware failure and my OpSys upgraded to 64bit and since then I
can not even get the MySQL linking in LO Base to even start!!



It it is fairly rare for people to suffer from catastrophic failures and
data loss using mysql - most of the time, it is usually possible to
salvage most, if not all of one's data providing one takes an interest
in the manuals on how to administer such a database server (and there
are a plethora of them, not least Oracle's own documentation).



So if you are happy to keep lots and lots of backups, and spend lots and
lots of time re-building everything at almost monthly intervals - and by
re-building I mean the Database Tables, redesign all your Forms and
set-up all your Queries and Reports from scratch - then go with it,
otherwise give it a miss.



It is also not strictly necessary to keep backups of the mysql database,
although it is indeed a recommended practice. Again, the documentation
is replete on how to do this safely.

From the interaction I've had with you on and off the list, I would say
that you have been unfortunate with regard to some of your expectations,
in that you did not wish to, or failed to, understand what it meant to
have a database server, and didn't wish to spend time understanding how
it worked in case things did go pear-shaped. I can understand this from
a user perspective, and in that case, choosing mysql as your backend
database engine was probably not a good idea, but as you found out for
yourself, neither was the embedded hsqldb.

My own experience with mysql databases has been rock solid in terms of
data integrity now for more than 10 years, including various different
types, from stock management, IP rights management, accounting, etc,
although I will admit that interaction with StarOffice, OpenOffice.org
and LibreOffice has caused some issues, but this mostly lies with
limitations or bugs within those programs and not mysql itself (barring
a few connector driver problems).

Fact of the matter is that databases when used with LO, embedded or not,
probably require more work than most "Access-users" are willing to put
in. There is no "simple", "out-of-the-box" solution for such users when
attempting to switch to LO, everything will be a compromise of sorts, be
it form design, reporting, stability, multi-user access, etc.

LOBase was always designed with the eye of a database administrator in
mind, and the attempted switch to a user-centric orientation just didn't
quite happen (for various reasons within Sun, and then Oracle). However,
what we have got is not bad as things go, providing that one can accept
its limitations (or alter one's work flow to work around them).


Alex







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

--
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-03 Thread Bruce Hohl
Base and some of its limitations (including enbedded HSQLDB) are well
described here:
https://wiki.openoffice.org/wiki/FAQ_(Base)

The last two times I needed a multi user database accessible over the web I
went with a LAMP approach.  The *upfront* set up and learning curve was
higher but *less* time is required over the life of the project
(development & maintenance) as these tools have exceptional stability and
performance, have very few bugs, excellent documentation and require no
client side maintenance.  AND, it's far more rewarding developing the
application versus fighting the bugs and limitations of your tools ... as
often happens when using Access, Base and their like (been there, done
doing that).


On Wed, Aug 3, 2016 at 6:15 AM, Alexander Thurgood 
wrote:

> Le 02/08/2016 à 00:23, Ian Whitfield a écrit :
>
> Hi Ian,
>
>
> >
> > *Re: The LO Base discussion* - just my "Penny's Worth"!!!
> >
>
> > The only way I got any (sort of results) was by using MySQL as the
> > backend but it took a couple of months to get it working and after a few
> > months even that crashed on me. I recently had to re-build my computer
> > after a hardware failure and my OpSys upgraded to 64bit and since then I
> > can not even get the MySQL linking in LO Base to even start!!
> >
>
> It it is fairly rare for people to suffer from catastrophic failures and
> data loss using mysql - most of the time, it is usually possible to
> salvage most, if not all of one's data providing one takes an interest
> in the manuals on how to administer such a database server (and there
> are a plethora of them, not least Oracle's own documentation).
>
>
> > So if you are happy to keep lots and lots of backups, and spend lots and
> > lots of time re-building everything at almost monthly intervals - and by
> > re-building I mean the Database Tables, redesign all your Forms and
> > set-up all your Queries and Reports from scratch - then go with it,
> > otherwise give it a miss.
> >
>
> It is also not strictly necessary to keep backups of the mysql database,
> although it is indeed a recommended practice. Again, the documentation
> is replete on how to do this safely.
>
> From the interaction I've had with you on and off the list, I would say
> that you have been unfortunate with regard to some of your expectations,
> in that you did not wish to, or failed to, understand what it meant to
> have a database server, and didn't wish to spend time understanding how
> it worked in case things did go pear-shaped. I can understand this from
> a user perspective, and in that case, choosing mysql as your backend
> database engine was probably not a good idea, but as you found out for
> yourself, neither was the embedded hsqldb.
>
> My own experience with mysql databases has been rock solid in terms of
> data integrity now for more than 10 years, including various different
> types, from stock management, IP rights management, accounting, etc,
> although I will admit that interaction with StarOffice, OpenOffice.org
> and LibreOffice has caused some issues, but this mostly lies with
> limitations or bugs within those programs and not mysql itself (barring
> a few connector driver problems).
>
> Fact of the matter is that databases when used with LO, embedded or not,
> probably require more work than most "Access-users" are willing to put
> in. There is no "simple", "out-of-the-box" solution for such users when
> attempting to switch to LO, everything will be a compromise of sorts, be
> it form design, reporting, stability, multi-user access, etc.
>
> LOBase was always designed with the eye of a database administrator in
> mind, and the attempted switch to a user-centric orientation just didn't
> quite happen (for various reasons within Sun, and then Oracle). However,
> what we have got is not bad as things go, providing that one can accept
> its limitations (or alter one's work flow to work around them).
>
>
> Alex
>
>
>
>
> --
> To unsubscribe e-mail to: users+unsubscr...@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+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-02 Thread jorge
Hi all:

For collections, there are two programs on GNU /  Linux Ubuntu and
usually on others Distributions:

1) GCStar

2) Tellico

Both have multiple options to import and export information. By the way,
my little knowledge can't permit to me to share with you what kind of
data base use them or if when have a lot data, they will come slowly,
but this are my 1 cent to this topic.

Regards,

Jorge Rodríguez



El mar, 02-08-2016 a las 10:39 -0600, Ken Springer escribió: 
> On 8/1/16 12:13 PM, Girvin Herr wrote:
> > On 07/31/2016 07:36 PM, Ken Springer wrote:
> > 
> >> I understand the concept of Front End/Back End, but never have dealt
> >> with it.  Nor have I ever used MySQL, Mariadb, or others.  Access and
> >> a bit of dBase is all I've ever used, and in general, even then that's
> >> more power than I've ever needed.
> >>
> > Ken,
> > Actually, IIRC, Access has both a client and server built in.  The user
> > isn't normally aware of it.  In my experience with Access 1.1, the
> > server is called the "Jet" server.  Today's Access may no longer use the
> > Jet server, but I am sure something like it is still in there
> > somewhere.  I must admit the Access bundled concept is addictive.  As a
> > newbie to databases back in the 90s, I liked it and it was a shock and a
> > learning experience to wean myself off of it and go with the industry
> > standard forms of client/server architecture and the SQL language.
> 
> You've just mentioned the big "roadblock" for the average person to make 
> use of databases.  They are too complex to learn and use for most 
> people.  That's where the "all-in-one" solution is a better answer. 
> It's a lot easier for the average user to wrap their heads around and 
> then use it.
> 
> What happens?  The average person fills up spreadsheet after spreadsheet 
> of flat file data.  My brother-in-law is a perfect example.  Years ago, 
> he was putting their music collection into a spreadsheet.  When the 
> sheet got to large for RAM and his computer crashed, he started 
> splitting into multiple spreadsheets.  But that made their goal of 
> printing their entire collections of songs, alphabetized, impossible.  I 
> took the spreadsheets and combined them into Access 97, created an input 
> form and reports, and everyone was happy.
> 
> Even getting people to use a flat file database like Database Oasis 
> would be better than a spreadsheet.
> 
> > Since then I have learned a lot and find the latter concept very
> > powerful.  In your case, if Access and dBase had/have more power than
> > you ever needed and that power is all that you will ever need, then the
> > LO internal HSQLDB engine is probably a good choice for your application.
> 
> It may be, if this was a single user issue.  But we need to be 
> compatible with MS Office without having enough Windows systems, where 
> as I can lay my hands on 3 other Linux systems that are being unused.
> 
> > Now that you mentioned dBase, you may, or may not, be aware that LO has
> > a dBase option.  But a limitation to it that I found is that older
> > versions of dBase files are not supported.  I have some old dBase 1.x
> > files with dbase programs that will not load into LO, let alone run.
> 
> I didn't know this, but must admit dBase is probably not the best answer.
> 
> > Girvin
> >
> >
> >
> 
> 
> -- 
> Ken
> Mac OS X 10.8.5
> Firefox 44.0
> Thunderbird 38.0.1
> "My brain is like lightning, a quick flash
>   and it's gone!"
> 
> 

-- 
Atentamente,

Jorge Rodríguez


-- 
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-02 Thread Jaroslaw Staniek
On 1 August 2016 at 21:49, Girvin Herr  wrote:
> On 08/01/2016 11:35 AM, Jaroslaw Staniek wrote:
>
> On 1 August 2016 at 00:16, Girvin Herr
>  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@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 

Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-01 Thread Ian Whitfield

*Hi all*

*Re: The LO Base discussion* - just my "Penny's Worth"!!!

After a 5+ years effort to use LO Base I have given up completely!! It 
is *NOT* usable at all in it's "out of the box" set-up, ie with the HSQL 
engine. It is totally unstable, crashes frequently AND - *MORE 
IMPORTANT* - trashes all you data when it goes down!!! This seems to be 
something to do with the compressing that the program does as you exit 
the program.


The only way I got any (sort of results) was by using MySQL as the 
backend but it took a couple of months to get it working and after a few 
months even that crashed on me. I recently had to re-build my computer 
after a hardware failure and my OpSys upgraded to 64bit and since then I 
can not even get the MySQL linking in LO Base to even start!!


So if you are happy to keep lots and lots of backups, and spend lots and 
lots of time re-building everything at almost monthly intervals - and by 
re-building I mean the Database Tables, redesign all your Forms and 
set-up all your Queries and Reports from scratch - then go with it, 
otherwise give it a miss.


I have searched for a suitable replacement. I run Linux here, and have 
looked at many programs. In desperation I was keeping things going using 
LO Calc and this is not easy. The rest of LO is fine and I use it a lot 
but base is the (VERY) weak link in the chain. This not only my opinion 
- if you dig around you will find many reports of this.


Early this month I gave *Kexi* a second try and I'm finding it very 
workable. It is still a bit "young" but does everything I want for my 
Database and I'm very comfortable with it. It is "All-in-one" using 
SQLite as the engine and the only major problem I have come across is 
the program crashing during Form design but frequent (say every 5min 
saves) seems to get round this. Doing actual work with the finished 
set-up has so far proved Rock Solid. It's worth a look at and stay with 
it long enough to learn its rather different layout and way of doing thins!!


Have fun - I am and very happy to be away from LO Base.

All the best

IanW
Pretoria RSA






--
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-01 Thread Girvin Herr

On 08/01/2016 11:35 AM, Jaroslaw Staniek wrote:

On 1 August 2016 at 00:16, Girvin Herr
 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@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.


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





--
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-01 Thread Girvin Herr

On 07/31/2016 07:36 PM, Ken Springer wrote:

I understand the concept of Front End/Back End, but never have dealt 
with it.  Nor have I ever used MySQL, Mariadb, or others.  Access and 
a bit of dBase is all I've ever used, and in general, even then that's 
more power than I've ever needed.



Ken,
Actually, IIRC, Access has both a client and server built in.  The user 
isn't normally aware of it.  In my experience with Access 1.1, the 
server is called the "Jet" server.  Today's Access may no longer use the 
Jet server, but I am sure something like it is still in there 
somewhere.  I must admit the Access bundled concept is addictive.  As a 
newbie to databases back in the 90s, I liked it and it was a shock and a 
learning experience to wean myself off of it and go with the industry 
standard forms of client/server architecture and the SQL language.  
Since then I have learned a lot and find the latter concept very 
powerful.  In your case, if Access and dBase had/have more power than 
you ever needed and that power is all that you will ever need, then the 
LO internal HSQLDB engine is probably a good choice for your application.


Now that you mentioned dBase, you may, or may not, be aware that LO has 
a dBase option.  But a limitation to it that I found is that older 
versions of dBase files are not supported.  I have some old dBase 1.x 
files with dbase programs that will not load into LO, let alone run.


Girvin



--
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-08-01 Thread toki
On 31/07/2016 19:32, Ken Springer wrote:

> Personally, I like the idea of the complete database package, as I think
> it makes it easier for the average person to create something useful for
> them.

How much functionality does the Access2Base extension offer, in terms of
making it easier to create  queries, forms, reports and modules/macro?

jonathon







-- 
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-07-31 Thread Girvin Herr

On 07/31/2016 12:49 PM, Ken Springer wrote:

On 7/30/16 3:30 PM, jorge wrote:

Hi:

On GNU / Linux / Ubuntu, and of course in other distributions, there are
to program that you would probe because could help you to export Access
DB to open document:

1) MDBtools (View and export MSAccess db)

2) Kexi of Caligra Suite that say it is able to read MS Access db


Thanks, jorge.  I'll have to check with my "conspirator" on how much 
effort in learning he's willing to do to create a Linux database.


Ken 


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.


I am using LO Base as a database client (aka "Front End") on Linux and 
connected to my Mariadb database server using a Java "connector" 
driver.  I do this because the LO internal HSQDB has limitations that 
MySQL and Mariadb do not have.  You may consider this if your 
database(s) are large or complex.


Years ago, I had my data in an access (1.1) database and needed to port 
my data to MySQL.  I managed it by using the option in access to output 
the database as a comma-separated file, much like a spreadsheet ".csv" 
file.  I then was able to set up MySQL to import this file into its 
database format.  Of course, as some others have noted, the forms and 
reports needed to be recreated.  At this time, OpenOffice (before LO was 
available) did not have a database client which would work with MySQL, 
so I chose an open source client called Rekall and had to recreate my 
data entry forms and reports.  It was labor intensive, but needed to be 
done.  Then Rekall went bust and I had to find another client.  By then, 
OpenOffice had Base, which would talk to my MySQL database engine.  I 
did not need to do anything with my MySQL database, but I did have to 
recreate all of my data entry forms and reports yet again - more labor.  
So, the bottom line is that any time you change database clients, expect 
to recreate the data entry forms and reports.  There is no standard for 
them.  One big advantage to using an external database such as MySQL or 
Mariadb, is that they use standard SQL, while the LO Base HSQDB database 
server uses a non-standard version of SQL.  So, using HSQDB could lock 
you in to it.


My databases are critical to me.  All of my database software decisions 
were based on being able to easily port my data to another client or 
server and not need to recreate it.  Depending on the size of your 
database, that could take much more time than recreating just the forms 
and reports.


Hope this helps with your decision.  Good luck.
Girvin Herr


--
To unsubscribe e-mail to: users+unsubscr...@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


Re: [libreoffice-users] Re: Compatibility of LO Base with Access databases

2016-07-31 Thread Harvey Nimmo
On Sun, 2016-07-31 at 13:32 -0600, Ken Springer wrote:
> On 7/30/16 8:40 AM, Harvey Nimmo wrote:
> > On Fri, 2016-07-29 at 20:53 -0600, Ken Springer wrote:
> > > The subject says it all, how successful is Base in importing
> > > Access
> > > Databases?
> > > 
> > > LO 5.0.x
> > > 
> > > --
> > > Ken
> > > Mac OS X 10.8.5
> > > Firefox 44.0
> > > Thunderbird 38.0.1
> > > "My brain is like lightning, a quick flash
> > >   and it's gone!"
> > > 
> > > 
> > Unfortunately, MS Access users were spoilt with the 'complete'
> > database
> > package supporting tables, queries, forms, reports and
> > modules/macros.
> > Although its 'openness' or performance or compatibility with the
> > rest
> > of the MS Office suite leave much to be desired (in my humble
> > opinion)
> > the MSaccess package is a (more or less) complete solution.
> > LibreOffice
> > on the other hand cannot match the user comfort (yet!).
> 
> Thanks, Harvey.  Not the answer I was hoping for, but the one I 
> expected.  LOL
> 
> Personally, I like the idea of the complete database package, as I
> think 
> it makes it easier for the average person to create something useful
> for 
> them.

Well, it is probably unrealistic to expect a 'complete' solution for
the complete porting of a database from a proprietary solution to an
open source one, bearing in mind the number of fields of API issues
needing attention and the understandable resistance from the
proprietary side to supporting a free solution and all that that
entails with risking divulgence of company secrets to a competitor.

What one can hope for from LOBase with time is growing maturity and
user comfort in the area of the forms, reports and macros. My
impression is that it is slow in coming.

What I appreciate very much in LOBase is the back-end support for
diverse databases (e.g. mysql/mariadb etc). This, at least, opens the
door for developing the database backend (schemas, tables, queries,
views) with other tools until the hoped-for user comfort arrives at the
front-end.

Cheers
Harvey

 

-- 
To unsubscribe e-mail to: users+unsubscr...@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