I’d be keen to see anything supporting using python to code queries, forms and reports rather than using the GUI.
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.
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.
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).
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.
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.
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).
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.
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):
- Ability to create form interfaces to view/enter/delete data (mini-apps)
- Ability to create & save mini-databases in one file (.mdb or .odb).
- 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
√
This is not recommendable with Base.
Only Access can create accdb/mdb.
Trivial with embedded Firebird, easy with HSQL.
1 Like
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.
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.
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
I was more thinking of the gui, wich sometimes just doesn’t know some of the available functions (and yes, I’ve seen several added). Not my problem as I use SQL without gui, but in this thread it is a topic.
I’ve never seen that. Thank you.
This is very insightful. I have not yet braved FireBird or the Wizard, but your explanation hints at a larger issue I have noticed in my brief exposure to Base: Code smells of a lack of good software foresight and good planning. I’m experiencing behavior that indicates memory leaks (runs slower and slower then locks up computer) and inexplicable inconsistencies.
It feels like a project that rather than furiously keep fighting bugs, to take a breath, do a deep code review and focus on simplification, focusing on core unique functionalities and consolidate code. But C++ will always be buggy IMHO. I’m not smart enough to know what the most cost effective solution is - maybe AI + Rust when the tools become available?
Please no “C++ will always be buggy” and “let’s rewrite in Rust” nonsense. (Well, at least I’m allergic to that, and will quit reading this otherwise. And most of all - the “AI will help coding!!!”)
Now about that visionarie’s “I know what all of you need to do” stuff. Well, in the world of The Document Foundation, which is not a dictatorship, and all the development is scratching own itch - you have no power to tell who should do what. So - people can dream as much as wanted, but only doing things themselves, or hiring someone and having things done for money, or - finally - hoping for the best - are the only options. (The option of TDF doing that for its funds is ~real, but needs its members’ support; so - becoming a member may be also a reasonable option.)
1 Like
and Java is evil.
A simple upgrade to HSQL2 would have avoided all that trouble.
1 Like
It’s really good to hear the TDF is not a dictatorship – and by implication the Foundation is open to suggestions. Sorry if I came across as ‘telling you what to do’. I didn’t even realize until just looking up who you are that you were a developer of LO. Thanks for what you do.
But if something isn’t working - and any objective observer would admit that Base has significant issues - one would think that the Foundation might be interested in community input. I for one would happily pay $100 for a ‘dream version’ of Base. But I’m not convinced the software engineering behind it is 1) genius enough to do such planning totally independently nor 2) willing to accept outside input on this
Again, this is not a “do it my way or else” comment. It is intended a honest input exploring Base and Base Tutorials for the last week, using both HSQLDB & MariaDB connection, using both Linux Debian distro supplied 7.4 and Latest LibreofficeDev 25.8 daily build versions and experiencing what one might kindly call Windows 3.1 level instability and inexplicable inconsistencies within the app (metric here, SAE there when US locale and no central units control)
Just because software is Open Source doesn’t mean it should be poorly designed.
I didn’t start this thread, titled “Who destroyed base?”, and as a believer in the benefits of FOSS (mostly the freedom part, but also the ‘scratch your own itch for free’ part), I am not here to bash LO. But sometimes the Emperor has no clothes and it is time to find a tailor.
PS I am not about to get into a flame war about Rust vs C++. For all I know, all Base needs is more testing etc. But it is true that Rust prevents a lot of run time bugs and seems to be growing in popularity. From what little I’ve used it, it seems more pleasant than C++.
The question is not “should it be poorly designed or not”, and even not “is Foundation interested in input or not”. It simply is “what do you think you achieve writing your ideas here” - and I might imagine, that you think that Foundation gets your input by that. And my point is: no it does not. Here you are sharing your opinion with other users and mildly interested individual developers. The foundation does not rely on Ask (unfortunately); and hence my “become a member” advice.