[Solved] Add same name, DOB and current date to 10 docs

[gmarriott]

When a new person joins our group, we need to provide the newbie with 10 documents with his/her name, date of birth (to distinguish between two different John Smiths) and current date. I assume Calc for data and Writer for docs. Using Windows 7, OpenOffice 4.1.2

[RusselB]

I'd suggest learning how to use Base, which is the database component of OpenOffice, and is meant for dealing with data.
Calc, while it can be used for data, does have limitations in that aspect.
As to your documents, I believe that Base, again, can handle this portion of your query.
NOTE: Base has a very steep learning curve, but if you plan on using this for a while, it's worth the time.

[MrProgrammer]

Hi, and welcome to the forum.

Put people in a database with (at least) two fields: Name and Date of Birth.
• You can use Base: File → New → Database → Create a new database and then create a table, fields, and populate it.
• Or, if you have existing database software on your system, you can use that to build and populate the database. Then File → New → Database → Connect to an existing database.

we need to provide the newbie with 10 documents …

Next, do File → New → Text document and use Insert → Fields → Other → Mail merge fields → {YourDatabase} → {YourTable} → Name → Insert → Date of Birth → Insert. Add other text on the page to create the document for the new person. The date will come from Insert → Field → Date. It's probably easiest to put all 10 "documents" in the same file, so use Insert → Break → Page break and build the subsequent documents. Finally use File → Save As → File Type → ODF Text Document Template → ✓ Automatic file name extension → Save.

When a new person joins our group …

Add the new person to the database. Open the template. Press F4 to open the database window → {YourDatabase} → Tables → {YourTable} → {Select the new person's record by clicking to its left where the green triangle is} → Data to Fields (outlined icon). That will populate all the fields that you created. Save the file and send it to the person.

Read about databases, fields, and mail merge in the Help, in this forum, or in the Wiki. Note that we have a separate forum for Base tutorials. A search for "mail merge" will yield thousands of topics.

If this solved your problem please go to your first post use the Edit button and add [Solved] to the start of the title. You can select the green checkmark icon at the same time.

[gmarriott]

We don't need to have a database of names, instead it would be great if it just 'forgets' the previous entry.

[jrkrideau]

We don't need to have a database of names, instead it would be great if it just 'forgets' the previous entry.

I seldom use data bases, but IIRC you could manually delete each former name but why? Storage cost is nothing. Once you have a table of names you can use it for other things. For example, your CEO needs to know how many people over the age of 40 and living in Mongolia do you have? Trivial in a data base. Nightmare if you have to do a manual search of paper records for 1,000 employees.

[gmarriott]

We already have other boxed software that tracks group users info (but does not allow the output needed to tag the 10 docs), so to do this would just be a duplication.

[Villeroy]

That other boxed software is most likely based on a database.
Ask the vendor of that application about the database and if/how one can connect to it (ODBC or JDBC or dBase?).
Connect a Base document to the database.

If this is too much high tech, you can still copy the same record set to 10 documents or use one of the 4 alternative methods linking spreadsheets to each other.
[Tutorial] External Links In Calc

[Lupp]

ooo81845DataPrint.ods

(126.67 KiB) Downloaded 115 times

(If there are Writer documents the OP is not allowed to rework substantially, my contribution will not be of use to him. I do not suggest a way to get the same data into 10 different Writer documents. Insofar you may judge my post 'off topic'. Hoping the requirements concerning the formats for the prints are not too high, I suggest to do the printing from Calc. If the prints use the same paper tray everything can be done by one file. If not, additional Calc files can reference the query results from the first one without any forms hokum. Nowadays a group of cells can prettyprint a page nearly as refined as a Writer document. I will now focus on the spreadsheet/database argument.)

We are often told keeping data, evaluating them and preparing forms based on them (including prints like in this case) should exclusively be done the database way.

I dare to object.

There are circumstances where I also would prefer spreadsheets for the purpose. There are prerequisites of course, too, and there are rules to observe. I will not publish a handbook this way about all these implications, however. The most weighty prerequisite should be that the original data can be regained in case of a failure of the spreadsheet part. Using spreadsheets there is no way to implement automatisms of data security and of data integrity on a level comparable to that coming ready-made with "real" database software. But: An odb "solution" using the HSQLDB AOO comes with and living in a single file on a single computer is no more secure than any other single file on a single computer. It will also be open to accidental destruction by the developer-user himself as any system not enforcing a protective rights management. In the given case we know already that the data are primarily maintained using the box thing. It is outside of our scope whether this application is "good" or not. We only know that it neither does allow for a useful export of the data needed for the prints nor it is capable of/allows for designing appropriate forms for printing.

Regarding these facts I took the time in this specific case to check both ways:
(1) Creating a HSQLDB database with (LibO in my case) our Office based on imported data from an already existing Calc document, and
(2) Empowering that existing document by some enhancements to perform the needed query and to prepare (roughly, admitted) the prints.

I did not finally succeed on the first way. Having imported the data (with a bit of trial and error, admitted) and created the query I was tired of the job and paused a bit. Then I thought of the possibly upcoming need to add another field to the data or to adapt to changes of the structure of the original source ... and to adapt the query... Ok a DB professional will do that by routine within a minute, I suppose . I cannot.

Thus I switched to the second way. As I am more experienced here, it is obvious to me that I can prepare the query to also work with a variable number and an arbitrary arrangement of the field columns (except ID in my implementation). If the requirements for the prints can be satisfied by printing from the Calc document itself, the preparations are simple. No forms needed at all. ... Ok, it is only a reduced example, but it works, I know how it does, I can adapt it easily to changing needs ... I did not return to the first way now to complete it. I only can attach the result of the spreadsheet way therefore.

Most of the time I needed was, of course, consumed by the writing.

(I am not experienced with database design, and by far not on the level 'Villeroy' is. In fact I just designed a few databases "off production" with the sole intention to learn some of the basics, and left it then to those whose job it was. My experience with databases was more affected the view of a user who was - for some time - forced to use databases designed by others at work. This was not at a retailer's cashier but concerned with planning, organising and deciding. This on a level requiring a bit of creativity. The detours forced upon me by the misbegotten database design trying to be fool-proof where no fools were and trying - next to - to make protection the only aspect relevant for data at all drove me mad now and then. Thus I can understand that the OP is not eager to fight a useless argument with the 'vendor' of his box thing.)

[Villeroy]

@Lupp
You can connect a database to your spreadsheet and the contained spreadsheet lists will (almost) behave like database tables. This is a matter of a minute. If you want a little bit more (direct write access) you save the spreadsheet list(s) in a dBase directory and connect a Base document to that dBase directory.