I have no clue what has been broken in recent versions. I’m a heavy user of Base. All my forms, some of them rather complex, do work with LO 24.2.
1 Like
LOL.
Basically, it’s complete conspirological %censored%. What happens is just a clear reflection of what paying userbase needs most. Commercial companies are simply not interested in personal database solutions. They pay for what they use. They don’t pay for what they don’t use.
One needs to have a very specific mindset, to invent this “strange” argument. OK, one evil corporation decided to destroy a part of a product - imagine how? by paying development in other parts of the product! Perfect strategy. Let us not notice the fact, that any other company that would happen to need Base, and that would hire any L3 support developer to implement the needed changes, would undo the effect. Let us not notice the fact, that no such interested paying customer appeared in more than a decade of LibreOffice history. Let us just invent attractive theories of villains plotting their dark plans of destruction, without even describing the problem clearly (which was mentioned at least three times already here: in reply #6, reply #18, and now in reply #21).
@Villeroy : If forms have been created and text controls shouldn’t be designed in 3D (haven’t designed so) and fonts for the controls aren’t set to default height you don’t recognize a difference between LO 7.4.7.2 and LO 24.2.
And if you are using Linux with KDE please don’t use multiline textboxes. I don’t use this kind of boxes in most of the forms so the bug doesn’t appear for me, but background of multiline textboxes won’t be shown with KDE and content wont be refreshed.
So: Using Base isn’t the main problem. Creating of forms, which will show the design I want, is a problem.
By the way: When creating databases for other people and they ask how they could help I always answer: Donate for TDF and write “Base support” as reason for the donation.
I always start LO with SAL_USE_VCLPLUGIN=gen because gtk is even worse. My productive databases need to run on Windows where all this bling-bling seems to be more stable. Form controls work almost perfectly under Windows, and they look always the same.
format_textbox.odt (27.7 KB)
Both controls of your document will be shown here (LO 7.5 or newer, KDE) without background. So if I switch in a database to next row I will see the content of the first row also. Cant read the right content any more.
Older Versions of LO (LO 7.4.7.2) will show the background and 3D also, when set and also the right font size 10 pt, which I could see in the properties for the font.
Have a look of the fonts of your screenshots. In the properties I could see 10 pt by default, but the fonts appear as 8 pt.
See all the bugs I have also posted here at 2024-01-14.
Well, it’s just a formatting issue with work–arounds. It’s far from being “destroyed”. @EasyTrieve is a troll. He does not even mention his OS, let alone any concrete issue.
1 Like
Maybe here:
BTW, I’ve reported lots of Base bugs over many years:
NONE of them have been fixed! A few years ago I just stopped trying this approach.
But now there are many new Base bugs. I thought it couldn’t get worse, but it has. I haven’t even reported a single one of the new bugs to Bugzilla because NONE of the others I ever submitted ever got worked on, so what’s the point? Angry and sad at the same time!!!
LO Base is … rather was the only decent database front end available on Linux. Now there is none.
I think the LO policy of accepting money to work on particular parts of LO is foolish. Any money that comes should be to work on all of LO or the money should not be accepted.
As to those of you who think Larry Ellison would not ever do this sort of thing, well I say to you don’t be naive. He isn’t a billionaire for no reason. He didn’t buy a whole island for himself just out of kindness. He is a shrewd guy, and a real shark.
For a brief time I worked at Sun Microsystems as a contractor writing software. When Larry paid billions to buy Sun what he got was the buildings in Mountain View and some of the customers and the team at that time. Sure that was worth something, but what he probably thought he was going to get was Java, MySQL, and OpenOffice. But each of them he lost: Java leaked out to Google, OpenJDK and many others, MySQL to MariaDB (including the man who mostly wrote MySQL), and OpenOffice to LibreOffice. Sun’s SparkStation hardware to my knowledge never survived the CPU wars. So Larry didn’t get what he thought he was getting for his 7.4 billion dollars!
A relational database is a key part of data processing that’s been with us for 70 years. I’ve been working with databases since the late '70s where I worked at Hughes Aircraft on a mainframe using ISAM with EasyTrieve as the front end. Anyone who doesn’t understand how important this component of data processing is, is really missing something big (literally). For example, most of the web has MySQL underneath it via WordPress. Even this forum runs on a huge database!
For LO not to insist that Base remain a solid component of LO is very foolish I think.
2 Likes
I had a look at some of your issues and added comments namely 108471, 108547, 107788 and 105039.
Looking at your screenshot, I can hardly spot any issue that has not been around since 2005 when “the Base component” had been added to OpenOffice.org. Yes, there are UX issues, poorly written help files and bad defaults but they have been around sincec decades. Nobody destroyed Base in recent versions.
1 Like
@EasyTrieve : Screenshot only shows all open bugs. I could also find resolved bugs reported from you: 16 bugs special written for component Base.
By the way: I could find 378 Base-bugs I have reported. Only 127 aren’t solved at the moment…
2 Likes
@Mike, Ok, my bad. You’re right, a few have been fixed over all these years.
But still, between Robert and my reports alone, that still leaves much to be done.
My hope would be that every report be addressed in something like months, not years, and 99% of things fixed, not 15% or so, or whatever the low number is now. … AND that especially new bugs be dealt with so that things aren’t getting worse over time.
I also use Calc and Writer and at times Draw. They don’t have any bugs I know of.
I wish I could help more. I hate to just be a complainer. I did think that taking the time to carefully report bugs was of some minimal help. At one point I spent nearly a year learning C++ but at 65 I’m aware that I’m really too old to deal with this huge code-base, no matter how much I tried.
It’s hard to describe how disrupting having Base not working properly is. I had used it for so very many things, accounting fortunately I am still able to limp along with it, though the user interface is now broken in so many ways that it makes it a real pain to use. It’s also an embarrassment when I try to use it to help my girlfriend.
tdf#104768 doesn’t require any c++ 
feel free to answer Olivier’s last comment (from 2021) so that we can finalize a solution to close it !
and more generally, feel free to join
I can assure you that the other modules also have their own bugs, including Draw! I use Draw for my patent application drawings, and sometimes I wonder if I’ll have any hair left at the end of the day when using it. Granted, my is fairly specific, but more crucially, bound to the legal requirements of the patent application filing process.
Resurrecting this thread not to complain so much as to draw attention to interest in Base, an almost unique GUI personal database front end which has so much partially tapped potential.
I’m not an expert, and would have a hard time recognizing a design pattern if I ran into one in a dark alley, but I am an amateur in the truest sense of the word. Here’s my 2cents on LO Base after taking an SQL class years ago:
- Very steep learning curve, partly due to non-intuitive, almost arbitrary conventions and nomenclature (Forms Navigator → Forms are more akin to data sources than physical forms (surprise when nothing appears when creating a form etc)
- Non-standard symbols (* for SQL % etc)
- Inconsistent or incomplete implentations (relationships in GUI are not actually fully implement constraints as in Access, more ‘suggestions’ or design aid, depending on context)
- bugs (form designer field backgrounds offset due to unit conversion confusions, Report generator refuses to even open in Design view on Linux 7.4.7.2 version, random crashes, mostly from some newbie SQL error etc)
Suggested solutions:
USERS:
Get involved. Post bugs, fix bugs. I posted a bug report and within a week there it had been moved to a preexisting report (I overlooked) of the same bug and the confirmation inspired a regression fix.
Make video and text tutorials of practical, non-trivial applications. Thanks to people like Robert G (who I think may be one of the people who helped write the book on 7.2 https://books.libreoffice.org/en/BG72/BG7201-IntroductionToBase.html ) the rest of us have a chance to bootstrap our learning. And raise awareness of what does work in Base.
DEVELOPERS:
Share what you know - code big picture is hard for new users/developers to understand, and this software is a bit of an antique (Java?).
Don’t break things. Looking at YouTube instructional videos it looks like almost nothing has changed in 14 years. This has an upside of familiarity. But I doubt anyone will complain if some buggy behavior goes away provided it doesn’t break something else. And this includes Writer/Calc (which I suspect affect Base forms etc more than we imagine)
Make it easier to direct tokens of attention (eg development guides) & affection (eg $) to Base developers. Amazing what money can do for motivation.
Don’t wait for mega-corporations to fund development. It’s not going to happen. There is no financial incentive. Alphabet, Meta, Oracle, they all want our data in the cloud. Users controlling our own databases is the opposite of what they want (not being conspiratorial, only stating the obvious)
It’s hard for us to scratch-our-own-itch if we don’t really know how things are currently put together. Wikipedia article doesn’t even mention which language Base is written in (not complaining, just odd).
More generally, the bugs & problems I’ve seen so far seem to betray an underlying lack of adherence to organization or standards – ODBC connectors simply don’t work with relationships, units conversions cause strange GUI errors – which probably will continue to be a source of pain unless refactored for simplicity.
1 Like
@fpy Yikes. As usual, the politics are always more complicated than the technical. Or perhaps I misread that thread in my haste (there seems to be a lot of history to catch up on with LO Base).
Perhaps selfishly, I would like to believe that a cross-platform, GUI based GUI front end for SQL database (with optional built in database), would be a killer app for open source.
Yes, there’s Kexi, yes, there is Symphytum (my two closest runner-ups) but neither one does all that LO Base promises (albeit imperfectly achieves).
PS Just installed latest Dev version 25.8 today’s build and it’s quite nice. Not perfect, but Reports will open in Design View!
Office forms are attached to office documents, like web forms are attached to web pages.
Yes, there is an ambiguous meaning of the term “form”. There are logical forms vs. embedding form documents which themselves may be embedded in a Base container.
The Base thing evolved around the year 2005 (OOo1 → OOo2). “The crowd” wanted something like MS Access, a relational database in a single file where wizards lead you through the tedious process. * and ? are translated to % and _ as you can see in the SQL view of a query. You are free to use % and _ anywhere in the user interface.
IMHO, Base was best before it existed. OOo1 had no Base component, no Base documents, but it already had connections to existing databases (stored in the global config), queries (also stored in global config), forms and reports attached to office docs. Apart from dBase, it could not produce new databases from scratch. Database connectivity was an expert feature for people who were able to develop a relational database with a tool of their choice and who were able to understand how to make the relational accessible through logical (sub-)forms and reports.
Nobody tests complex Base apps on the Mac, let alone with all combinations of Linux components (Wayland/X, Gnome/KDE, packages from various sources). Linux distributors treat Base as a fishy extra to be installed separately.
Since many years (a decade?) I know, that I have to disable the use of gtk widgets, if I want to use Base.
I’m not aware of a similar ‘invisible virtual form’ concept in web development, only actual element render by the browser as part of the DOM, so I may be misunderstanding what you meant by comparing to web forms. I wonder if it would be possible to rename the ‘logical forms’ to improve user’s conceptual understanding of the mental model employed by Base to create forms and clarify their true role.
Long term, a clean revamp of the interface to more prominently indicate the role of core tools (like the Form Navigator) and group related things on one tab would be ideal.
By defautl, my distro came with 7.4.7.2 LO including Base - at least it was in the official repository. It appears to be reasonably stable. I did run into some compatibility issues (would not connect or display relationships) with ODBC connectors and found only one version of the JDBC connector/driver that worked with MariaDB server as expected, and that driver was an older one.
I downloaded the newer .debs in the (correct) suspicion that I could use newer .jar connector driver. But that lead to discovery of the Forms Field background bug. I have not yet even got around to testing the dreaded “Reports” section. I’m glad to see that more developer time may be spent on Base in the near future.
If I am understanding you correctly, it sounds like you are referring to use of Base primarily for OO tasks like mail merge etc. This would be a drastically reduced functionality and fan base compared to the advertised capabilities.
My naive ideal for Base would be provide a usable (by the 'crowd") alternative to MS Access, only FOSS and wider compatibility, both standalone & as a larger db server frontend. It would be nice to be able to prototype a front end using a local server (similar to the current HSQLDB) and then migrate it to a larger (MySQL/MariaDB/PostGreSQL) server, connecting to forms and all.
The ability to easily create a database + GUI forms nearly become a standalone app in itself. I know I would love to have a better GUI database front end than PhPAdmin.
We live in an age of data, whether it be tracking personal medical records, small business inventories, comparison shopping, vehicle maintenance & supply sources, due dates, mileage, etc. And do so more intelligently than an Excel spreadsheet.
Organizing data is something many people, especially technically inclined, want to do, but few of us want to spend a week untangling idiosyncracies and inconsistencies of a tool.
If so, this is truly sad, altho at least one other Debian based distro (Ubuntu) user confirmed my (apparently GTK widget related) form bug report which was easy to demonstrate on the current MX Linux XFCE/GTK Debian based system. That bug now appears to be patched on the latest daily build, but IMHO the default behavior should ‘just work’, so if there is no capacity to fully test interface niceties, a release candidate should have GTK widgets disabled by default, and a user interface ‘experimental’ option added for testing purposes until reliable at least on mainstream Debian/Ubuntu/Mint distros.
With current carelessness, user experience suffers and it really leaves a bad impression to have to tweak a FOSS app on a mainstream Linux distro after installing the official .deb. Base is a unique and potentially important piece of FOSS software which appears to be underestimated in value.
IMHO, LO Base first impression reminds me of an awkward teenager who hasn’t yet quite realized his/her superpower or unique qualities and true value to society, and gets easily distracted by dying spiked hair, tattooing skin, etc attempting to be what he is not and neglects the social polish required to thrive among normal people. But with time, he hopefully will outgrow this awkward phase and be recognized as a must-have app.