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

On 7/22/2012 10:34 AM, Andreas Säger wrote:

Enter raw data into a spreadsheet (Excel, Gnumeric, Calc, whatever), a text editor, some dBase application, a true database, whatever.
Connect a Base document to the tabular data source and design a report.

But that's the point isn't it. I've got to enter data into the spreadsheet. We're in agreement.

Why must I take the time, expense and trouble to "design a report" when I can get satisfactory results with a bare minimum of time, expense and trouble using Calc?

Clearly, you know Base and designing said report is no big deal for you. I think I may have opened Base once, and I simply don't have the time to learn it, nor the money to pay someone else to do the work for me. Especially not when a solution presents itself in Calc so readily.

Yes, your solution is elegant, ideal and based in academia where people have all the time in the world to learn applications and techniques and then design dream or "best practice" solutions. In the world of business it's about simplicity, speed, expense and return on investment. I can hire a virtual assistant from a third world country for less than $2 an hour, who already knows how to use a spreadsheet (not that cut & pasting requires much knowledge), whereas to hire a programmer to design a report would cost in excess of $8 an hour (and everytime I need a change I either have to go find that same contractor who now charges more, or start the interview process all over again; a time consuming task) - plus I still need to hire the assistant that ends up doing just about the exact same (busy) work anyway. So where is the economical benefit to your solution?

Your solution works for you because you have not considered the real cost of implementing it. It may be "best practice" from an academic, engineering and/or scientific standpoint, but from a SMALL business perspective it makes little sense. You've absorbed the cost of your own time and pegged it's value at zero. I'm taking real dollars out of my own pocket and paying someone to do the work. It's the same reason why people hire housekeepers - if the cost of the housekeeper were more than the employers income they couldn't afford to pay the housekeeper for long and would eventually have to clean their own house. You're cleaning your own house and that works for you. Great! I prefer to pay someone so I'm free to focus my time on what I hope are more profitable endeavors.

As a matter of fact, database forms (even Base forms) provide much faster and less error prone ways of data entry. In the last 2 years I replaced a dozend of useless spreadsheet lists with simple databases because "my users" never really got used to spreadsheet editing (navigation, dates, numbers, clear, delete, ...). Spreadsheets are too versatile for untrained users. Wrong data yield wrong results. My databases collect a thousand of manually entered records per month on a local network.

So really you're trying to apply a one-size-fits-all approach. My users (1 or 2 assistants) already know how to use spreadsheets so technically they're not "untrained", whereas your users do not know how. You collect thousands of MANUALLY entered records per month. I might have maybe a thousand or so records total, which can be cut & pasted from website to spreadsheet. My needs are different than yours. Any solution needs to take the customer's needs and unique situation into account and in this case I'm the customer.

For unsubscribe instructions e-mail to:
Posting guidelines + more:
List archive:
All messages sent to this list will be publicly archived and cannot be deleted


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.