Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


Andreas - thank you for answering.
You certainly noticed that in my mail was two (main) issues:
1. >> I asked for help with a database problem when LibreO-Base's basic function (DATEDIFF('yyyy'...)) calculates a wrong result; I hope that you realize how important and severe that matter is both for LibreO and for every user: if a user can't trust the calculations then better not to use LibreO-Base. 2.>> I pointed out that there must be a fault in the the function's programmed construction when the function requires the string 'year' in stead of 'yyyy' the latter form is the modeled in 'official' guides. They ought to be interchangeable.

Without answering or commenting the two points above, you sent to me a SQL command that - as to my experience - is bullshit
>>    it did not work in my database so I started to test it
>> I made a simple database backwards from your SQL command: one table "table" with tree fields (id, birthdate, age), inserted one record, let the query wizard make the query and copy-pasted (note!) your SQL command into the criterion field in column 'age' -- it did not work
>>    neither did it work as an expression in an 'extra' field(column)
>> your SQL command had syntax errors both in the command build and the characters used (e.g. ",', []) As you may understand from my message I had myself already tried to build up a SQL command similar to yours - but I was not good enough in SQL.

Question:
Does LibreO recognize expressions?  if so, what is the syntax?

And then a little psychology
In an recent other thread was a discussion about how to get more people to use databases - 'how to lower the barriers'. One point of view seemed to be that ordinary non-professional users feel it too difficult to design dbs and then also to use them. What do you think if considering my writings above?

I really want to think that you are an expert on databases - show it!
Please, try again and give me an adequate answer on my first problem.
Without wasting any more of your time.
Pertti Rönnberg

_PS: ref to Tom's and Dan's kind answers today_
Mathematics is an international language with it's commonly fixed rules.
And the only relevant answer is that the calculations in LibreO-Base (and Calc!) really follow the math's rules! As I mentioned in my mail: the result is not logical. An INT() function reduces 72,225 to 72(,oo...) and there is no excuse in the world to round 7,225 to 73! I am serious! I do use both Calc and Base in matters where the correct calculation is important.
I would not want to accept LibreO (nor OOo?) as a kindergarten play!
pr


On 16.2.2012 14:16, Andreas Säger wrote:
SELECT "Table".*,
DATEDIFF( 'mm', "BirthDate", CURRENT_DATE ) / 12
- CASE WHEN MONTH("BirthDate")=MONTH(CURRENT_DATE) AND
DAY("BirthDate")>DAY(CURRENT_DATE) THEN 1 ELSE 0 END AS "Age"
FROM "Table"

--
View this message in context: 
http://nabble.documentfoundation.org/Fw-LibreO-Base-is-lying-about-my-age-tp3749948p3749995.html
Sent from the Users mailing list archive at Nabble.com.



--
For unsubscribe instructions e-mail to: users+help@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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.