Description of the SWISSLOG Database


To work efficiently with SWISSLOG it is very helpful to understand some of the more important concepts of the SWISSLOG database. (This section covers more of Theory of Operation... OK, I know Hams don't like to read – they prefer to talk – however sometimes understanding basic theory helps very much – so, please READ this section. Thx de HB9BJS).

The Logbook-DB is the main database used in SWISSLOG. It is a relational database and contains a number of tables which are linked together. The four most important tables are shown in the block diagram below:

The six tables shown above make up the core of the station log for SWISSLOG. Let's take a closer look how a QSO is represented in these tables – however, first we will analyze the three basic elements which make up a QSO:

Now lets see how SWISSLOG represents these elements in the Logbook database:

The Callbook table contains information about the person who owns the call sign. In SWISSLOG, we call this the Station because there are other entities besides individuals who can have callsigns. The Station remains the same independently of which QTH it works. There is exactly one entry for each Station (callsign). Therefore, all information closely linked to the callsign is stored in the Callbook table. For example:

The PQTH table contains information about the QTH of the Partner. This is a very important table because most awards are based on the QTH of the partner station. For each station, there can be several PQTH entries. Actually, there must be a PQTH entry for each different QTH where you contacted the partner station.

Also, the Logbook table is linked to the following entries:

As you can appreciate, to retrieve all of the information about a QSO, you need information from all of the tables. In relational databases, it is easy to 'Join' tables to extract the information for a specific QSO. It is also possible to define 'virtual' tables (called views) which link together the entries in different tables and present the information as if it was a single table. In SWISSLOG, there are two defined views and generally you will be working with one of these views.

This may seem a bit awkward or confusing at this pointperhaps an example will make it easier to understand...

The following example shows a few QSO's I made with John, HB9JOI worked John at three different QTH's:

  1. His home QTH in Geneva
  2. His weekend QTH in Biel
  3. And when he was in France

Refer to the PQTH table belowyou will see three entries, one for each of his QTH's.

When I first worked John, he provided some personal information related to being a Ham, such as his name, his Ten-Ten and Dig numbers, and a few other facts that I put in the station comment field. This information stays the same and does not change when he operates from another QTH. Therefore, the data is stored in the Callbook table.

Myself, I also work out of different QTH's. If you look at the entries in the MyConds table, you will see four different QTH's, however to make this example easier we will assume, that I had all QSO's with John from my Home QTH.

I have used a different color to designate each QSO's with John at his different QTH's. You can see that QSO's 3, 4, 6, and 7 where made when John was operating from his weekend QTH in Biel. The information about this QTH for example the Region and the QTH-Locator are stored only once in SWISSLOG, but they are linked to these QSO's.

Question: Guess what happens if I change a field which is contained in the PQTH table?

Answer: The field is changed for all QSO's linked to this PQTH entry. Therefore, if I edit QSO number 3 and change the QTH Locator from JN37OD to JN36OD, then the QTH Locator is changed for all four QSO's (number 3, 4, 6, and 7) because they all share the information for the QTH entry named JN37OD.

If you attempt to make a change like this, SWISSLOG will ask you if you want to change the value or, do you want to create a new PQTH entry for John. So, if John was operating portable at a different QTH for QSO number 3, and the QTH Locator for QSO 4, 6, and 7 is correct (JN37OD) you would need to add a new PQTH with a QTH Locator value of JN36OD. SWISSLOG will then link QSO number 3 with the new entry.

By default, Swisslog handles this automatically and user don't need to worry about all this, creating new PQTH entries when needed. However, it's explained in case user enables the "Issue warning if a new QTH is needed" in the QSO Entry window (disabled by default), because SWISSLOG will prompt if you want to change the current PQTH entry or you want to add a new PQTH entry. Then you need to know all this in order to decide properly if you want to add a new QTH or change the existing one to apply this value in all QSOs with this station.

This may seem overly complicated, however it provides the flexibility necessary to handle many different situations that arise and still maintains the integrity of the database by not linking data incorrectly.

Callbook (Stations)
Call Name Ten-Ten DIG
DF1SD Kuno 99999 0381
HB9JO Jo 111111 4711
PQTH (Partner QTH Table)
QTH-Name QTH DXCC Region QTHLoc
HomeQTH Geneva HB9 GE JN36WF
JN37OD Biel HB9 BE JN37OD
/F France F 037 JN27ON
Logbook (QSO's)
QSONr Date/Time Band Mode RSTR
1 26.04.03 08:00 10m SSB 59
2 03.09.03 11:33 20m SSB 59
3 04.09.03 10:14 15m CW 599
4 07.09.03 15:06 20m SSB 59
5 10.09.03 20:11 40m SSB 58
6 11.09.03 23:27 15m CW 599
7 12.09.03 O9:57 20m SSB 59
8 22.09.03 10:22 20m SSB 59
MyQTH WCONDS EVENTS
MyQTH MyCall QTHLoc Rig Contest
HomeQTH HB9BJS JN47QA TS950  
Weekend HB9BJS JN46SU SB104  
OE9 OE9/HB9BJS JN47XD FR290  
H26 HB9BJS JN47KH TS950 H26

Copyright © 2004 SWISSLOG
Last modified: 18 dic. 2022