Latest Awards
Logbook 3.0 Documentation
Contents
QRZ Logbook
- About
- Subscriber Benefits
- Customizing Display Options
- Multiple Logbooks
- Shared Logbooks / Manager Access
- Logbook Widget
- Callsign Changes
- Frequently Asked Questions
Confirmations
ADIF Files
Logbook of the World
QRZ Awards
Technical
I Still Need Help!
Multiple Logbooks
The ability to create and maintain multiple logbooks is a key QRZ feature of our Logbook.
Before you create a logbook (unless one has already been created for you), it is essential that you understand a few basic concepts.
How the Logbook Finds QSOs
First, when the QRZ server stores a new QSO report, it searches the database for a possible match to confirm. Let's say that your call sign is XX1XX, and you had a QSO with YY1YY. You input the QSO with YY1YY, indicating today's date as 2023-02-01. The server will then proceed to look in its master database for the logbook that handles YY1YY during the date and time indicated in your report. There could be two logbooks for YY1YY, and the server will select the one with dates that fit.
This gives rise to the notion of Logbook Date Ranges. A date range is specified as the starting day for a logbook and its ending day. The date range can't be permanent, and it can't be perpetual because, over time, call signs get reused. This allows us to track who owned a call sign, when, and to whom the credit goes. When you create a logbook for present use, the starting date should always be "today" and the end date some distant time in the future, such as your license expiration date. If you keep your license and don't get a new one, this logbook will last you for years.
Let's say that you have been using the QRZ Logbook for a while, upgraded your license, and received a new call sign. Yes, it's time to create a new log book. Having your new call sign, you should adjust your existing Logbook's date range to have it end on the last day you held the license. Then, create a new logbook for the new call sign that starts today.
Many people resist starting a new logbook. They want to keep using their old logbook because it catalogs all their operating achievements. We get that. We also understand that in the time of manual logging on paper, most people just wrote down their new call sign in the same old logbook and kept on operating and logging. That, however, won't work here. The system will look for a book having the name of the new call sign instead.
The bottom line is that if your call sign changes in any way, it needs a new logbook. Note that operating awards are given to people, not to call signs. This means that when a person applies for an award, we allow them to specify which of their multiple logbooks, or all of them, to use for the calculation.
So, with those things in mind, the following rules apply:
- Every Call Sign needs its own Logbook
This is essential and yet often misunderstood. A call sign is defined as what you transmitted over the air. If, for example, you were operating portable and decided to add a /P to your call sign, that's a new call sign in the eyes of the logbook. The system will consider it a new call sign when you add anything to it, whether it be a slashed prefix or a suffix.
- Logbook Date Ranges for the Same Callsign may never overlap
You can have multiple logbooks for the same call sign, but they must cover unique, specific time periods. The system expects to find only one true match when given a call sign and a date. The system fails if two logbooks cover the same call sign on the same day.
- A user may create a Logbook for any callsign
You don't have to own a call sign to create a logbook for it. You can arbitrarily create a logbook for a dummy call sign and start giving it QSO reports. This capability means that QSL managers can create and maintain a QRZ Logbook on behalf of their client(s). The same anti-collision rules apply for the date ranges because they are global and not per-user. This also means that a mistake by a user in date-ranging a logbook could prevent some other group from using it. The QRZ administrators will assign and/or revoke privileges as necessary when this happens.