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

Am 16.03.2012 15:40, Nino Novak wrote:
On Friday 16 March 2012, 15:00:41 Andreas Säger wrote:
Am 16.03.2012 11:09, Nino Novak wrote:
It could be used as reference on how to use Base.

Well, this would be like a reference on how to use a programming
language. Either you can actually use it or you follow more or less
obscure instructions.

I rather thought of a reference implementation, not a language reference.
A reference tutorial if you like :-)

A non-theoretical primer for people keen to learn to create (simple)
databases. An initial nucleus ;-)

Don't you think, that this would help much more than saying, that it
requires expert skills?


It would really help if LibO would drop the entire Base component with
address sources and everything, letting the user import raw spreadsheet
data as embedded XML structures into serial letters. So they get a
feeling of empowerment when they freely drag around, import and export
their data copies. They would not even blame anyone for the results.
An abstraction layer like Base is beyond user's imagination even though
it can be used in very creative ways. Using software tools in creative
ways is mere expert skill.

Erm - yes. However...

Sort of ... I'm the wrong person for this kind of discussion. I'm a simple
user, who wants to learn, no, wait, who wants to create his own address book
using LibreOffice. So please, talk to LibreOffice component architects (or who
ever regards himself as appropriate person to discuss dropping components).

But please help me to create my simple address book :-)


The trick is that you can use any type of address book if you know how to work with software tools in creative ways. Dump your data in a text file, a spreadsheet or (much better) use dBase and then build a query with the right field names matching your letter template(s). This is what nobody really understands. Spreadsheets come very handy to compile lists from csv import, clipboard, keyboard and other connected sources. You can freely drag around data and compile the right male/female greetings together with snippets like [you | insurance owner | your son | your daughter]. But no matter which software I am using, finally the list should match with one of our well prepared letter templates. This requires a more or less sophisticated query with the right alias names.

Nobody but YOU can build the right database for your purpose. If your address data cover information about company relations or family relations then you take advantage of a relational database instead of flat dBase, spreadsheet or plain text.
This is more about user-ability than usability.

But virtually nobody here ever talks about concrete *DATA* to process. Everybody expects some ready-made stuff without any clear specification about ready-made for what.

We have several types of address sources and every now and then it is my part to compile tomorrow's address lists fitting to one of our letter templates. Then I leave a note to the co-worker about the source name and query name for the serial letter to print, she opens the template with prepared field masters for address, salutation and stuff, then she sets the right data source, writes the letter and due to a well known "unfixable bug" she specifies the source query once more when printing. She does not bother about file types nor database connections nor field names. That was my job.

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.