Base question Re creation of unusual database

I am trying to make a database of hymns that we sing in Church that will cover 15 years or so.
WHen I try to create a database, the wizards cut in and want me to select a load of irrelevant fields, like name, address, business, etc. WHen I try to rename them to what I want I am not allowed to do so.
I want to create a database with totally different field names, and print reports from the data for the choir (lists of hymns for the practices etc,)
I have struggled away at this for many hours over many days, and made no headway.
In WORD and MS OFFICE, I could link a table in a Word Document to a Mail Merge document as a report and it worked well, except that after 10 years or so, I ran out of memory.
And I don’t loke Microsoft’s direction of travel, so I’d rather use something open source.
But I can’t find a way to do this usint writer documents, and I am finding the system in LibreOffice inflexible and impossible to make work.
It is entirely possible that I am coming at it from the wrong angle, given my history over the years.

All the help files I have addressed so far assume that I want the categories provided in the wizards, which are unsuitable .

Is there anyone please who can give me advice or point me at some useful information to allow me to do this. If this is the wrong forum for this query, I apologise - please let me know where it sould go.

My efforts to edit the result of using the wizards lead to the suite crashing.

I am trying to make a database of 14 fields all of which can be searched. None greater that 100 chr$, some being just 8.

Many thanks

PJF 00001

A lot of questions in one question, so I have to decide where to start… has also documentation. Did you find/read the Base-Guide on the following page?
English documentation | LibreOffice Documentation - Your documentation for LibreOffice

Writer really is no database. Some of the habits using M$-Software result on having only Word, or Word/Excel but no Access, so they added mail-merge within Word.

For LibreOffice there is no need for this, as there always is a database. IMHO Base is quite flexlible as I’m using csv-files as Text-database, Calc-Tables to feed mail-merge, lokal Sqlite-Databases, a remote MariaDB and also have an embedded HSQL. There is a lot to be added, but flexibility would not be on my list.

To your real problem: Have you tried to do without any wizard?
Just defining a new Table gives you complete freedom to create your fields.
As you seem to have an existing file you can check, wich Type of Columns you need.

What do you put into your database? Full text or only references to the other data.

Thanks for your prompt reply.

I implied in my answer that it might be (indeed, was) my long history and familiarity with MS office mailmerge that was limiting my thinking. From your answer, I think it was. What you have described is massive flexibility. It’s my thinking that isn’t at present!

Every time I tried to make a new table, the wizard appeared, and I struggled (for ages) to get away from them. They were the main problem for me.

Last night, following your prompt that it actually could be done, I finally managed to make a table without invoking the wizard. Once I found out how, it was easy. it just took me far to long to find it. So now I have an empty table, with an Index Key making the first field.

Up until now, I have been using a master odm document to link 4 odt documents together, which are too big when combined to live in memory at the same time.

My data lives in those 4 odt files, and each entry in them (one for each week) consists of 15 fields. All the entries are text only, and some are blank. There are dates also, but I have struggled with storing them in date fields, as they convert to incomprehensible numbers, probably because of field definition errors that I’ve not got to grips with.

However, because I don’t have to do any date-based calculations, I simply store the dates as text. I can sort them accordingly (I use the American system for computer-based dates. Sorting is easy)

Extracting the data from the master document is the next step, and then follows populating this database table with it, and checking for errors.

The list has entries going back 15 years, and it’s all a bit daunting. I’m an organist, dammit!

But I’m getting there, thank you.