OOo Off the Wall: Fielding Questions, Part 4 - Mail Merges
Mail merges are a means of using fields to create multiple copies of a document. They got their name because one of the most common uses for the tool is to address letters to different destinations. However, the same process can be used for other purposes as well, such as personalizing a form letter. If you choose, you even could use mail merges as a form of conditional text. Of all the uses fields have in OpenOffice.org Writer, mail merges is one of the most useful--and the most complicated.
In the version 2.0 beta, merges theoretically became simpler with the addition of the Mail Merge Wizard to the Tools menu. In practice, however, the wizard's usefulness is limited. It's designed specifically for merges that address letters or, assuming that you have Java Mail installed on your system, e-mails. Other merges still have to be done manually or with the older wizards for faxes, labels or business cards.
Moreover, although you can puzzle through any of these wizards without fully understanding merges, you can use them more efficiently if you first try to do a few without a wizard. Working without the wizard helps you understand the three parts needed for a mail merge and how they work together.
Mail merges require three separate documents:
The data source: a database, a spreadsheet or a Mozilla or Thunderbird address book that contains various information. In version 2.0, OOo refers to all these types of documents as databases, but keeping the distinction between data sources in general and true databases seems less confusing.
The source document: a Writer document with mail merge fields added from Insert > Fields > Other > Database. The mail merge fields are placeholders that indicate what fields from the data source are used. You can use other fields to signal how information from the source document should replace the mail merge fields.
The target document(s): a Writer document(s) produced when the mail merge is used. The target document(s) replaces the mail merge fields with information from the data source. Target documents are sent to the printer or saved as files.
Before you begin a merge, all three of these items need to be set up.
Before you can use a data source, you must register it with OpenOffice.org. Prior to version 2.0, data sources were registered from Tools > Data Sources. However, as of version 2.0, they are registered using File > Tool > Database and a different interface.
In addition, in previous versions, the original data source file appears to have been registered with OOo. In version 2.0, information from the data source seems to be extracted from the source file to create a new database using the new Base format (.odb) in your home directory.
To register a data source in version 2.0:
Select File > New > Database. The Database wizard opens.
Select the Connect to a New Database button. The Database Type drop-down field becomes available.
Select the type of data source from the Database Type field. Almost any sort of proprietary or open-source database can be used, providing that it has either ODBC or JDBC connectivity. You also can use Thunderbird or Mozilla address books, spreadsheets and text files. Both spreadsheet and text files can be formatted in any manner supported by Writer, including MS Office files. A text file, however, requires a consistently used de-limiter to designate rows and columns. It is worth using only if you don't have another way to record data.
If you are unfamiliar with databases and have under 1,000 records, a Calc spreadsheet probably is the most useful type of data source. You can use a spreadsheet with more records, but be prepared for delays in opening and saving the file.
Click the Next button to continue.
Enter the path to the data source. If it has a password, click the Password required box. Then click the Next button to continue.
Click the Yes, register the database for me button, followed by the Finish button.
Enter a name for the new database and then click the Save button.
The new database has been created and now is available for use.
-- Bruce Byfield (nanday)
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Stunnel Security for Oracle
- Tips for Optimizing Linux Memory Usage
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Managing Linux Using Puppet
- SuperTuxKart 0.9.2 Released
- My +1 Sword of Productivity
- Doing for User Space What We Did for Kernel Space
- Parsing an RSS News Feed with a Bash Script
- Tech Tip: Really Simple HTTP Server with Python
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide