Who destroyed base?

English
#42

The vast majority of LibreOffice Base documents connects to some spreadsheet for mail merge or label printing. People put database data into sheets and run the mail merge wizard, which creates a registered Base document on the fly. The additional Base document as a connector is understandably confusing to many users.

OpenOffice.org could connect to all kinds of external databases you had a driver for. There was just no way to generate any new database out of OOo. OOo could do the same things on stand-alone documents as Base can do today on embedded forms and reports. Some differences since then:

  • HSQL has been introduced as a free, open source database engine to create new databases from scratch.
  • The report-builder extension superseded the old-fashioned reports based on Writer tables and became the report engine built into LibreOffice.
  • Named parameters have been improved, so you can use them as function parameters as in Upper(:named) (to me the most important improvement in 2 decades)
  • Some built-in SDBC drivers have been added (Postgre, Maria/MySQL, Firebird).
  • Restrictions have been lifted, bugs have been fixed (lots of regressions among them), but basically, the old OOo1 had the same functionality without any “Base document”.
  • Recently, I found out how to create external Firebird databases from scratch, even with experimental features disabled. Experimental features enabled, you get embedded Firebird, which is a bad thing anyway.

IMHO, introducing the “Base document” was a mistake, embedding databases even bigger a mistake. The existing functionality with forms and reports on documents was good enough, however deserving lots of improvements.
Sooner or later, you need to extract the database for safety, security and/or multi-user access.
Sooner or later, people ask for switchboard solutions or how to hide the Base document window from the user.

+++
In our small business, we do not deal with many office documents. However, most of our templates and documents are connected some data source on the local network (dBase, Calc, HSQL, MariaDB). I only use 2 spreadsheet documents: one merges queries from multiple data sources into pivot tables and import ranges feeding calculation models with recent data, the second one “publishes” non-confidential records from a confidential database.

#43

LOL, Villeroy, you’re a good man I think, but how do you know this? I doubt anyone can know what the vast majority of how Base is used. It’s like saying that a hammer is used mostly for driving nails. It might be true for some users, but lots of what a hammer is used for is not driving nails.

A tool is a tool, to be used however one sees fit.

I’ve been using relational data bases of one sort or another for 47 years. The first one I ever used was called Easytriev and I used it in the '70s. But I’ve used dBase, Access, IBM isam, and a dozen other relational databases or front ends for them.

Nowdays and for the past 10 years or so I use Base almost every day. It’s the very best that Linux has to offer. But only once have I used it for mail merge.

I use it for accounting, organizing information, invoicing, ordering, data accumulation, and too many other things to enumerate. I once used it for the front end for a data driven web server.

And the vast majority of websites these days are connected to a database. The older ones use a relational data base. The newer ones use a simpler key/property database that can be huge and distributed, like what Amazon and Facebook use.

Base is an extremely important tool. Without it one needs to move to Windows and use Access.

#44

Really? :scream:

I can only guess out of 23 years of OpenOffice support during which too many users get lost of their mail merge connection because they

  • (re-)moved the ods.
  • (re-)moved the odb.
  • moved the ods and the odt template to a new setup but not the odb.
  • moved everything to a new setup but did not register the database.
  • tried to replace the spreadsheet with another one, which may fail for any above reason plus changed field names.

A fairly recent license of MS Access costs no more than 20 bucks nowadays. IMHO, this indicates that the era of desktop databases is over. LO Base has never been a replacement for MS Access. It is a little pretender with no budget nor man power.

possibly running on Linux, and none of these has anything to do with any office suite. Nevertheless, you may be able to connect Access and Base as alternative desktop clients in order to do productive things on prem.

#45

Thanks for confirming my suspicions. You seem to be assuming a completely different use case that I (and many others I presume) want to use Base for and if all the TDF marketing hype is to believed, of which Base is capable: Namely a client side front end GUI database tool, fairly unique in its abilities.

I can barely understand your posts by asking AI what you mean by OOo1 vs OOo2, but according to AI, you seem to be yearning for a version of OO PRIOR to 2005! That’s over 20 years ago, software changes, matures, and so do use cases. I have never used Base for a mail merge and doubt that I ever will. What I want is a FOSS MS Access type personal database that can also be used to prototype and then manage and allow visually pleasing data input. Have you ever tried to enter hundreds of musician events in MySQL using only PhpAdmin? Have you ever tried tracking a lot of data in Excel spreadsheets without losing track of column headers, scrolling off the page? Have you ever tried to track other complex data like medical labs in a normalized fashion to avoid integrity problems that invariably creep in with spreadsheets?

I can understand that. Software that tries to do everything for everyone rarely does anything well. Perhaps it does need to be spun off from the LibreOffice suite. However Base has a huge untapped market here apparently if (as you believe, but I question) it is only being used for Mail Merge. Search the web for a FOSS GUI MS Access alternative and you will inevitably end up back at Libreoffice Base, despite its flaws and lack of dev love and even its loyal users who perhaps underestimate its potential.

IMHO, the base document is a necessity, if only to save form layout, connection data, and so on. I don’t know if there might be a better way to do this, but a generic SQL database really cannot do this, and it feels like the OO suite is a bit overkill for forms (perhaps this is what you are meaning).

As for embedding databases - yes & no. Having a quick and dirty way to prototype a true SQL database is priceless, even if it is a flat file like SQLite – IF you can later migrate to a larger server. Not everyone wants to manage a MariaDB server on their laptop.

I can’t comment about your statement that “the existing functionality with forms and reports on documents was good enough” because from the perspective of 2025 I have no idea what functionality that included in 2005.

I am currently running LibreOfficeDev 25.8 and aside from a few crashes when saving tables, and some confusion about how to import CSV data (it is not intuitive at all). I have no plans or intentions to ever buy or us MS Access, if only for the reason it only runs on Windows.

EDIT: I have no idea where you can buy a legal copy MS Access for $20 (official price is $179 currently), but even if you could, it would lack all the benefits of OSS which are too numerous to repeat here.

#46

Just wanted to point out where it all started (as a hidden expert tool) and how it got where it is (an overambitious prototype). Without any resources, Base will never compete with MS Access. Nevertheless and from a certain perspective, this broken thing is more useful than Calc, because it can actually do what users try to do in Calc (and fail).

To answer the topic title # Who destroyed base?, it was destroyed by popular demand (“something like Access”) back in 2005.

#47

Only one hint: If Base GUI won’t exist most of us wouldn’t know LibreOffice could handle with databases. There exists a database together with StarOffice - Adabas. With this kind of database I have tried the first steps. When OpenOffice appeared I had looked for a database and didn’t found it. I changed to MySQL/Apache/PHP.
.
Base GUI isn’t perfect, but it is better than nothing. Let us help other people to use it!

1 Like
#48

Absolutely true! Despite all its flaws, Base was a brilliant concept, however imperfectly implemented. I don’t think popular demand destroyed it. In fact, based on my comparison of 25.8 daily dev build to 7.4.7.2 distro repo Linux version, it continues to improve.

No disrespect to the developers, this is a huge project, but some of the interface still have room for major improvements. Just one small example to illustrate the larger point: Yesterday I finally figured out a way to get around having metric units in some parts of the app, SAE (English) units in another. No units settings anywhere to be found in Base or LibreOffice, nor any rational reason to have two different units going on simultaneously under different controls (the app obviously understood the difference as it would consistently convert from my input units to whatever it wanted at that point). I outwitted it by changing locale to UK from USA and now everything is metric, which is what I prefer anyway, but the large question: Who codes an app in such a ad hoc, disjointed way? A committee?

Also, user interface fails to take advantage of modern UI expectations such as we have come to expect in apps like Google Draw (multiselection equi-distribution of controls etc). Copy & paste works more like you would expect a spreadsheet to work (replaces selected data rather than copying - I don’t care about that really, one becomes accustomed.

Exactly! Despite intermittent crashes, I’ve always recovered. And despite not fully understanding the obscure way that forms (logically datasources) relate to tables and subforms, I seem to be able to getting things to work – however tediously. Since there is really nothing else that comes close, and data is such an important part of modern life (ask any corporation), I really hope that interest will continue in Base so it can continue to empower the private end users. And don’t forget to donate if you agree.

#49

I’d be keen to see anything supporting using python to code queries, forms and reports rather than using the GUI.

#50

Yep, a script analyzing tables, their relations and data types could generate useful form skeletons with list boxes and multiple levels of subforms.
The major problems start with misconceptions about tables, relations and types. If you don’t follow the rules of normalization, you can’t get far with queries, forms and reports.
Typing plain simple SQL into a text editor is way faster and straight forward than trying to use “the Base GUI”, particularly when you know what you need, even more when errors need to be fixed.
A second database development tool can help a lot. Database development is not an option for everyone. It requires higher abstraction capabilities than a spreadsheet or text documents.

Create_Database_Tables1.ott (39.7 KB)

For embedded HSQL and Firebird, I can offer a “relation designer” free of any macro code. It is a Writer doc containing an SQL script generating a set of 5 tables connected by a one-to-many, many-to-many and a one-to-one relation. Each table consists of the required keys and a name field.
Writer’s text variables allow some modifications, particularly giving meaningful names to the tables and name fields. Everything is properly quoted and not nullable by default.
Finally, you copy the resulting draft of a database into a text editor, add more columns as needed and then copy the script into Base’s SQL window.
The whole thing could be improved with conditional fields (skip any refs to tableX if tableX is not needed). In the end, writing SQL CREATE statements is just a text game. SELECT statements can be much more sophisticated.

#51

I think you (and @Villeroy ) are still missing the point of the GUI. It’s not for manipulating SQL per se. As everyone knows, there is CLI for that. It’s for viewing and editing data, making mini-personal databases. That is what GUI is designed for. We can argue all day and night which GUI is better (DOS like interface or fancy Aero look) but the point is, some human brains actually operate visually, and GUI is THE way to interact visually AFAIK.

Again, we’re not talking about industrial spam mail mergers. I could care less about those. I’m talking about organizating research, prototyping a database. Primarily using Forms – a much better way to view and edit data than scrolling thru spreadsheets. At least any spreadsheet I have seen.

By the way, I take back what I said yesterday about Base not being destroyed. I’m using 25.8 and for the life of me cannot figure out how to File > IMPORT data into a table from .csv or .ods file as chat GPT thinks (and I agree) that I should be able to easily do.

I’m not a dummy. I just don’t understand what the mental model is behind Base’s GUI interface.
[EDIT: Found Paste Special does work, but have to be in Tables list view (not in the table itself as any intuitive person might assume from any prior experience with spreadsheets, and only if you hold your mouth right while choosing RTF, append data, and make proper column selections of an already created table, etc] A very brittle process.

#52

This is a cool scripting tool. Thank you (only briefly checked it out but obviously a lot of thinking went into designing it. The fact you had to do this speaks volumes for Base’s usability (or limitations thereof).

#53

It occurred to me that I have not explained clearly enough what I see as a key use of Base. Here’s an example WIP I’ve been working on this week for tracking potential vendors for contractor services. I’ll try and upload my Entity Relationship Diagrams and a screenshot of my progress. It isn’t pretty but the goal is a dashboard for consolidating actionable information.

ERD_VendorsServices
ERD_VendorsServices970×552 112 KB

ContractorsDbWIP_ScreenShot
ContractorsDbWIP_ScreenShot1375×636 89.7 KB

#54

Seems you miss the point that a GUI is just a visual way of issuing commands to a database. The commands can be issued directly or through the GUI. Base has the query QBE or Direct SQL. Another example: python-ooouno-ex/ex/auto/writer/odev_build_form at main · Amourspirit/python-ooouno-ex · GitHub has the main code in python-ooouno-ex/ex/auto/writer/odev_build_form/build_form.py at main · Amourspirit/python-ooouno-ex · GitHub.
.
(I understand these are Base forms though they are not used in that context. Can someone show me how? Interestingly iirc, coding that example demonstrates glitches with forms ignoring precise attribute sizes.)
.
A big advantage of coding objects rather than designing them through a GUI is forcing attribute consistency, things like height, width, alignment, color and font, things that can be difficult to achieve in a primitive GUI.
.
I’m most interested in coding reports in python but allowing users to modify them in the GUI.
.
I’d also like formatted queries (Discourse link bug - scroll to the bottom) but nothing like community forums to dismiss what you want as invalid.

#55

Of course they can! And one can create text documents using Vim or emacs or LaTex. And there are uses where those are the most appropriate tools. Horses for courses.

I obviously am still probably missing the point, as your statement sounds to me like saying that watching Netflix is just another way to listen to a vinyl record.

Can you please expand on what you mean?

My point (or intended point, however inadequately presented) was that there seems to be a need for a FOSS GUI form creation software (similar to Base - see screen capture in my previous post) that allows a more user friendly custom creation of data entry/viewing of a personal database. Something more elaborate than a standard address book or ‘to do’ list app, but not necessarily a corporate wide database management system (although some already exist no doubt). And doesn’t require the user to install a database server to create a small app that can be saved in an .mdb or .odb file.

AFAIK, this GUI might also involve some database manipulation, but to some degree I agree with you that generic SQL commands might be as good or better for the underlying table. What I’m most interested in is the form presentation and data entry. Some drag & drop is SQL is nice, but obviously limited, especially if done imperfectly.

I agree sort of. I know this was not directed at me, and I agree that LibreOffice Base transparency about schema etc seems a bit limiting (I still don’t know where to easily find all constraints like you can with SQL) But it also raises the question of why so many poo poo the idea of a GUI interface on a forum specifically dedicated to a GUI app.
EDIT: Just scrolled down to see your post about formatted queries. Yes, that is frustrating. Pretty formatting would make generic SQL so much more readable and might encourage more use of SQL vs whatever voodoo is going on to make forms/subforms/subsubform queries work (and all the yucky inconsistencies between table control field setup and a regular form field configuration).

#56

If a GUI works for you, you do you. I want both.

MS Access does it nicely and it is no more than allowing the grid layout attributes which are saved in Base tables to also be saved in queries. It’s ideal to format a table for analysis, or to slip into a word processor or presentation. You can even use the caption as the query name.

#57

True. But isn’t that called HTML CSS? Different forum.

I think we agree more than disagree, it’s just that we’re talking about two different aspects of Base. I’m referring to the visual layout of controls. I think you (and @Villeroy ) are focusing more on the database schema structure configuration of tables etc.

With regard to the former, I agree that control dimensional attributes should also be easily available (and they mostly are, somewhat).

But some retro comments here remind me of the early days of 3D graphics - I recall one guy commenting: Who needs a GUI when you can just enter the point coordinates manually? Now any 3D artist would laugh at you for even suggesting one do art purely with text. Yes, of course there are settings that can be configured, esp. in 3D used for CAD, where precision is critical, but they all have GUI WYSIWYG viewport . Same with programs like Inkscape, GIMP (or Photoshop).

Plus, there are other ways to get OCD pleasing alignments - see Google Draw for example. Select multiple object (controls?), choose Distribute > Horizontally (or Vertically) and voila! Very visually pleasing result. No copy pasting Position X, Y attributes etc. But if you want to, you can easily do so.

Again, CLI MySQL is a beautiful thing - just not LO Base’s raison d’être.

MS Access, despite its age, sounds more refined than Base from your description (I haven’t used it for 10 years) but I no longer want to depend on Windows and Base seems to be the best alternative despite its obvious shortcomings (which may be fixed eventually one would hope). The truly unique attributes which both share, and few or no others have (I would love to hear of an alternative):

  1. Ability to create form interfaces to view/enter/delete data (mini-apps)
  2. Ability to create & save mini-databases in one file (.mdb or .odb).
  3. Ability to optionally move migrate such mini-database prototypes to connect to & manage external servers

These are the three killer features – everything else is gravy.
How they are implemented is of no interest to me – I would be perfectly happy if all the internal database creation and configuration was done in standard SQL (preferably with code formatting preserved).

In fact, I suspect that such direct SQL would be less bug prone. I know there is a “direct SQL” button in Base, but I read that it can cause problems due to the way it is implemented - I don’t recall specifics. If anyone knows of a guide how to do the 3 things listed above in Base using Relationships (or MySQL) without dealing with the awkwardness of linked fields Forms/Subforms/SubSubforms etc

#58

√

This is not recommendable with Base.
Only Access can create accdb/mdb.

Trivial with embedded Firebird, easy with HSQL.

1 Like
#59

Why not? Is this a relative or absolute “don’t”? To clarify, I have no interest in .mdb compatibility, only .odb stability and performance. Is there some problem that I will encounter later as database grows (I am just building my first Base database interface and it seems to be easily transferable between my Linux computer and a Windows computer using two different versions of Base (backward/forward compatibility is not a trivial accomplishment).

And even if Base is not ideal, it doesn’t sound like there is a better FOSS alternative.

#60

It is much easier, when nobody develops on Base…
.

I don’t think many will complain, if a Access-like GUI will pop out somewhere (but the first question will be: Can I switch this off?)
But with very limited resources it is questionable if dreaming of a big project is the way to go, or just wasting time.
.
The project of integrating Firebird shows a lot of the problems we have with diverging databases.

As a PS:

If one activates “direct SQL” Base is not altering your queries, so your formatting is kept.
For the other mode I’ve seen in an example ‘/* comments */’ used to hold/keep a formatted copy of the query as work-around.

#61

It only shown one single problem: inclusion of an unrealistic but very populistic goal of creating an automatic migration between different database engines (i.e., something that automagically could take your carefully hand-crafter HSQLDB, and turn it into an identically behaving Firebird) has devastating effect on the project. When the task of implementing the FB support, the only reasonable goal of that project, was done, the other task - the migration wizard - was implemented somehow. When FB got out of experimental stage, the only thing that was too problematic was exactly that wizard - and that wizard had forced making FB - as a whole!!! - back experimental. A whole disaster.

Is there any real-world tool capable to migrate between different DBMSs lossless? We needed to focus on introduction of FB as the new default engine; then - if desired - moving HSQLDB to extension, for people still wanting to use those DBs (or, maybe, just continue supporting HSQLDB as a legacy - which at that stage would not mean dependency on Java (in this specific area), because we provided a Java-less default alternative). And that would make the project successful years ago. But - there is marketing. There is that “kill Java with fire”, which doesn’t want to stop anywhere except total extermination…

3 Likes

Impressum (Legal Info) | Datenschutzerklärung (Privacy Policy)   Content on this site is licensed under a Creative Commons Attribution Share Alike 3.0 license.