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


I hope to to condense and reply to all.

A person has spent arduous hours of entering/linking/formula-ing etc... on spreadsheets. It is not the optimum of data entry, as would be a database form. But it does do every thing they want it to.

Now, if a translation Calc (spreadsheet) to Base (database SQL) generated the the database, they would only have to make the data entry form.

Yes, this is an overly simplistic view, but it is what is being asked for by most.

Exp:
1. make a spread sheet, add data, add formulas, add look up references (internal or external) 2. Save as BASE. ?Do you wish to keep Calc data or create an empty database? Yes or No.
3. Learn how to create your first entry form in Base and add more records.

It is at this point the original spread sheet comes to haunt us. Items 1 and 2 become reiterative until user tires out and learns SQL.

It is not the who is bigger than who, but who is trying to get in, how many are left out and how may we help them to get in.

Carrot, Stick or Sugar with Medicine?



On 2/6/2012 12:24 PM, Paul D. Mirowsky wrote:
Everybody knows how write simple math statement as a formula. Everybody doesn't know how to right an SQL statement.

The largest failure to using database vs. spreadsheet is the refusal to allow tables to set up formulas in databases as they are in spreadsheets.

A formula interpreter would quickly resolve inherent coding fear of database.

Reason for not doing this. I don't know.



On 2/6/2012 10:37 AM, e-letter wrote:
Readers,

There was an interesting discussion which seemed to be about using
accounting principles/conventions with computer software.

Clearly the original poster forgot to dispense with traditional
thought processes and think critically about how new tools (first the
computer, then more specifically open source software) offers the
opportunity to develop new methods for solving problems.

We read the all-too-common scenario: an m$ fan wanting to use LO as an
m$ clone without learning anything new or assessing whether there is a
better way of doing things. As always, such people want open source
software users to help them for free. Please reconsider and revert to
using m$; the fact that the problem was solved using m$ proves this
option.

m$ users, please take the time to do your homework, research the
alternatives before asking for open source software to adopt the same
behaviour, mentality and sometimes inefficient process to performing
tasks as m$.

The example of organising identical data types into multiple
spreadsheets is so common, primarily because the average "office"
personnel is not introduced (nor willing to accept) to the power of
databases.

Realistically, we cannot expect someone due to retire soon to suddenly
change, but the next generation should be encouraged to be open minded
to using new ideas.

By the way, thank you for the hyperlink to the data pilot functions,
but should this type of functionality be performed by learning how to
use relational database queries?



--
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.