Open an embedded FB table with a date field.
Call the standard filter dialog and try to apply any reasonable filter. I always get an empty record set with LO7.3 on Linux.
Always something else. I’ve already made my point. Bugs exist in Base. Submit if wanted.
.
However,
.
Before:
Applied:
Using
Version: 7.3.0.3 / LibreOffice Community
Build ID: 0f246aa12d0eee4a0f7adcefbf7c878fc2238db3
CPU threads: 8; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
Calc: threaded
Is anybody testing the most fundamental basics (each and every GUI command, simple WHERE clauses with all availlable data types) before FB becomes the default engine for newly created databases?
Until recently I thought that the whole FB project is dead. Now I see it resurrecting in LO 7.4 without being tested thouroughly. I’m not interested in FB. I do not even use any embedded HSQL anymore. Most of our busines documents are connected to one database or the other. I have only one spreadsheet that is not connected to a database, even that one gets 2 values per week copied from a database. We use daily todo lists, label printing, mail addressing, what-if-scenarios and a little cash register. Everything is linked to HSQL server, local HSQL, dBase, spreadsheets and csv from various bank accounts (but not loaded into Calc). As a Base user I am not interested in a new type of embedded db that is even worse than the old one.
Then don’t complain about it.
Not for a lot of issues I see. I gave up on submissions a while back as there are few if any people to work on them concerning Base yet new issues crop up all the time.
That is not the first time. Last time trying to resurrect it was a flop also. Certainly not holding my breath here. Need a lot more people and planing to implement.
PowerFilter.FB.odb (41.6 KB)
Your work-around casting the dates into a string works well with my test database. See “Filter Form”. Nevertheless, I would rather choose anything else than embedded Firebird.