Any Manuals available for Spreadsheet and/or base,?

users
#1

To Users: I have not used either the Spreadsheet nor the Base parts of Libre office, as I do not know how to.

#2

To Users: I have not used either the Spreadsheet nor the Base parts of
Libre office, as I do not know how to.

I am not sure if a user with no prior knowledge at all can actually
use the current LibreOffice guides by himself without at least some
additional guidance.

In any case, take a look at

https://wiki.documentfoundation.org/Documentation/Publications

which includes guides for Calc and Base.

Regards,
Ady.

#3

Hi :slight_smile:
There is a Handbook for Base. The guide itself 'only' has the first
couple of chapters but each of those chapters is larger than manuals
so they might well be exactly right for what you need. Database
programs are much more complex than something like Writer.

A database program has 4 components in much the same way that
LibreOffice has about 6 modules/apps/components. In LibreOffice you
might use Impress for doing presentations but it's probably not the
best tool for writing letters or drawing objects. The 4 components of
a database program are
* Tables = these contain data in something that looks a lot like a
spreadsheet. Generally it is best to have your data in an "external
back-end". That means a separate program that you seldom open or do
anything with. Like a sock-draw you just keep things in it. Unlike a
sock-draw you don't have to open it to get things out or put them
back. A Calc spreadsheet could be a back-end but there are usually
programs that are designed for the purpose. Calc is for something
else.
* Queries = These do calculations, sort the data, apply filters,
bring data together from different tables. They do NOT create a
duplicate of the data. They just look-up what's in the table and act
on that. it's like looking in through a window. if a light is
switched on you see that happen through the window but it's not the
window itself that switched the light on and the window doesn't
contain a duplicate of the light-source. This is the main function of
the database program.
* Forms
* Reports
These last two are the way a normal user sees or uses the data. it's
only the designer who would look at the Queries. Base allows you to
use Writer to make the Forms and Reports so that normal users can stay
in familiar territory. A Form might show one of the addresses in your
address book and show their photo alongside (actually i have never
quite managed to do this but i think others have). Forms and Reports
can access the back-end data directly but to make your database more
robust and flexible it is better to make them take the data from a
query.

Regards from
Tom :slight_smile:

#4

Good morning. I'm new to this list, and thought it polite to introduce myself before I ask for help. So . . .

My professional career is one which has travelled a long and winding road. I began my university career studying aerospace engineering before deciding to become a parish pastor in United Methodist and Presbyterian congregations, where I served for about 27 years. Then I apprenticed and worked as a baker of bread for 6 years. Now, I am the co-Founding Pastor of a new church development (which will combine ministry and baking -- it's a story I'm happy to share, but one which is likely not germane to this email).

When I was in parish ministry, my wife and I used Lotus SmartSuite, including its relational database, Approach. I believe I was fairly proficient at it for the needs I had. But it's been 6 years of so, which means my skills are rather rusty -- and we've switched to LibreOffice, which means that some things are done in a slightly different manner. And I've found I need some help.

I am creating a relational database of our friends and followers. The first table I created was one called "Connections," because it is a "master table" keeping track of all the folk with whom we make some sort of connection. As you might guess, the fields (is that the terminology used nowadays?) include a CID (connection ID), which is an auto-incremented ID number field and the primary key, first and last name, address and other contact fields, etc.

I am now creating a second table to record the information about contacts we had with our connections during a particular fundraising event. My thought on the design of this table is that it would have the connection's CID, name, and the amount they donated. I figured that I'd again make the CID the primary key for this table, and create a relationship between those fields in the two tables. I would also like it set up so that I can enter the name in the event table and the rest of the information will be pulled in from the other table.

I created the new table and linked the two CID fields. But when I enter the name in the event table, it doesn't automatically pull up the information from the other table.

Any help would be greatly appreciate.

Doug

#5

Hi :slight_smile:
Sorry for the delay! We seem to be a little slow in the last couple of weeks.

The 2nd table probably needs it's own ID field (yes, it's the right
term) even though it's not really going to be used at all. Is each
row in the 2nd table unique to a Contact? or do some contacts have
more than 1 row in the 2nd table?

I suspect that the Event Table needs to be a Query rather than a
table. Queries look a lot like tables. It might need to be a Form
instead though and i would build Forms by basing them on Queries. The
Query would pull the information from both tables together then the
Form might be what you need to be able to type a name into in order to
get the details of that row of the Query.

I'm kinda clutching at straws here but i think you need to check on 3 things
1. Give the 2nd table it's own ID
2. Check the type of relationship linking the Connections table to
the 2nd one (ie 1 to 1, 1 to many, or many to 1, (many to many seems
unlikely!))
3. Try using an external back-end to store your data tables rather
than the internal one built-in

How you do that 3rd thing is still a bit beyond me but there are tools
such as Postgresql, MySql/MariaDB, HsqlDB and many others. I don't
know which is best but it probably depends on how large the tables are
likely to be. For any kind of contacts database it's likely to be
reasonably small so you could aim for the small, light and fast ones.
Regards from
Tom :slight_smile:

#6

Hi :slight_smile:
Sorry for the delay! We seem to be a little slow in the last couple of weeks.

No problem. Thanks for the reply.

The 2nd table probably needs it's own ID field (yes, it's the right
term) even though it's not really going to be used at all. Is each
row in the 2nd table unique to a Contact? or do some contacts have
more than 1 row in the 2nd table?

I suspect that the Event Table needs to be a Query rather than a
table. Queries look a lot like tables. It might need to be a Form
instead though and i would build Forms by basing them on Queries. The
Query would pull the information from both tables together then the
Form might be what you need to be able to type a name into in order to
get the details of that row of the Query.

I'm kinda clutching at straws here but i think you need to check on 3 things
1. Give the 2nd table it's own ID
2. Check the type of relationship linking the Connections table to
the 2nd one (ie 1 to 1, 1 to many, or many to 1, (many to many seems
unlikely!))
3. Try using an external back-end to store your data tables rather
than the internal one built-in

How you do that 3rd thing is still a bit beyond me but there are tools
such as Postgresql, MySql/MariaDB, HsqlDB and many others. I don't
know which is best but it probably depends on how large the tables are
likely to be. For any kind of contacts database it's likely to be
reasonably small so you could aim for the small, light and fast ones.

And thanks for the info. I'm off to read up on queries. I'm sure I'll have some more questions, and will ask them as they arise.

Doug

#7

Hi :slight_smile:
Sorry i meant to follow-up with soemthing for Calc but got distracted.
It's better to follow decent guides rather than my confusing
ramblings anyway. The official guides are here
https://wiki.documentfoundation.org/Documentation/Publications
The wiki does have other resources such as the FAQ
https://wiki.documentfoundation.org/Faq
although the Calc section is still being worked on, i think. The Base
section was the first one completely finished! :slight_smile:

Also video tutorials might be more helpful. There is a good series of
"Spoken Tutorials" being produced through funding from the Indian
Government at the moment. The English in them is top-notch and they
are very careful to ensure a very high level of quality
http://www.spoken-tutorial.org/list_videos?view=1&foss=LibreOffice-Suite-Calc&language=English

Regards from
Tom :slight_smile:

#8

Hi :slight_smile:
The best place for documentation is
https://wiki.documentfoundation.org/Documentation/Publications

There are also some good video guides at
http://www.spoken-tutorial.org/list_videos?view=1&foss=LibreOffice-Suite-Base&language=English
although i haven't worked through the Base ones yet.

I'm still hoping that someone else here will be able to give better
guidance about using Base.
Good luck and regards from
Tom :slight_smile: