When you upload your log to Club Log, it automatically skips over or ignores some QSO records if it encounters any of the following trivial issues:
  • A QSO record is identical in terms of the date, band/frequency, callsign, DXCC country, QSL status etc. as a QSO already in the log, or is within 30 seconds of an existing QSO (simple duplicates are ignored)
  • The callsign is less than 3 characters long (this catches CQs recorded as QSOs, zero-length calls, and other typos) or is "ERROR"
  • The callsign starts with an exclamation mark ("!" is used as a comment marker by some logging software)
  • The callsign in the log is the same as the station call.
  • The band is higher than 13cm (Club Log is limited by design to 160m to 13cm inclusive but excluding 220MHz and 900Mhz)
  • Records are not separated by EOR markers in the ADIF file (the ADIF file must comply with the ADIF specification)

Club Log does not generate messages for these trivial issues. However, some log discrepancies are more serious so Club Log emails you the details after your upload, as follows.

Errors
QSOs that meet any of the following conditions are categorized as errors and are discarded (these are not stored by Club Log):
  • QSO before 1945 (just like DXCC, Club Log's world starts in 1945)
  • Frequency can't be mapped to a ham band and the band is not explicitly declared (out-of-band QSOs)
  • QSO record has an invalid format (e.g. an invalid date)
  • Callsign belongs to an SWL (not a QSO)
  • The callsign cannot be mapped to a DXCC country by any known rule or exception

Warnings
QSOs that meet the following conditions are stored by Club Log but generate warning messages:
  • QSL date in the future
  • Unknown mode (to allow for obscure modes, these are recorded by Club Log as "digital" as a workaround)
  • Club Log disagrees with the DXCC country you have claimed  for a QSO
  • Dubious GB and GR calls (these are compared against Club Log's database of known good callsigns)
  • Maritime mobile, aircraft mobile or satellite QSOs
  • Known pirates, slims, operations that have been declared invalid or not yet valid for DXCC (e.g. 1B-prefix operations and others where the DXCC desk is waiting or unable to validate the license paperwork) and so forth. These QSOs are stored by Club Log but the DXCC country is listed as 'invalid'.

Most raw logs contain simple typos. Club Log can't spot them all, only the ones that clearly bust the prefix e.g. KP1 or P5 logged recently, MO vs M0, or 1Z vs IZ. These normally generate warnings but some create errors if the prefix logged is invalid. 

Check through the report generated and emailed to you by Club Log after your upload to make sure you understand any anomalies it finds in your log. 

Errors and warnings are entirely normal, especially when you first start using Club Log. This is one of the main benefits of the system: it applies the DXCC rules, plus its database of exceptions and anomalous callsigns, in order to help you find and hopefully correct the mistakes that typically accumulate in any active DXers' log.


Real world example - A note from Timo, OH2BMH


Timo uploaded an old ADIF file to Club Log, and was struggling to find why some of his QSOs were missing. We discussed this on the Helpdesk, and Timo took the extra trouble to investigate. Here is what he said:


"I found the problem. It had escalated from the good old (?) DOS 
days. My first logging program was Swisslog and there were two ways to "force" special 
prefixes to a specific DXCC entity. One way was to update the country file with an exception 
and the other way was to add a prefix behind the call. The format was as follows (an example): 
4U9U-9U5. 9U5 wasn't part of the call but was used to tell the logging program that 4U9U is 
actually a station is Burundi. I thought that I had cleared all calls with hyphens, but I hadn't. 
It was easy to find the "hyphen calls" with my current logging program (HRD) and remove the 
pointer prefixes, and voila..... the problem was solved."