HamApps Support (VK3AMA)
On 18/01/2019 8:17 am, Michael Black via Groups.Io wrote:
That FCC database entry is perfectly valid. If you examine the schema, the second column in the above sql command is labelled "state". It holds the US State returned from the initial FCC data dump that is used to populate the fcc_lotw_eqsl.sqlite file. A null state for TO7D is valid.
The reason that JTAlert doesn't show a DXCC name for TO7D is not related to the fcc_lotw_eqsl.sqlite file, it is due to the Callsign not identifying the Country of issue. While most Callsigns identify their Country due to the Callsign naming and the ITU assignments. That is not possible for "TO" callsigns, there can be in a number of different DXCC Entities. Put TO7D into DXLab DXView and you will see that it also doesn't identify the Country.
The only way to identify the operating Country of the "TO" callsigns (and of some special event callsigns where the Country cannot be determined from the structure of the Callsign) is through Callsign overrides. JTAlert, like WSJT-X and many other applications use the cty.dat file for these overrides. TO7D is not included in that file.
As I type this, these are the current "TO" callsign overrides in the cty.dat file.
Note from the above three different Entities (FG,FM,FY) being used by "TO" Callsigns.
While the cty.dat file doesn't contain a TO7D callsign override, the JTAlert version of cty.dat (a much faster lookup sqlite build) now includes the override. If you install the latest HamApps Callsigns Database, JTAlert will start identifying that TO7D as in Guadeloupe. If you don't use the Callsign database, than when you will need to wait for the next JTAlert release (All JTAlert releases include internally an updated build of the cty.dat file)
de Laurie VK3AMA