Hi Ken/Lars,
I may have missed the original message from Ken, but since I've taken on the
maintenance of the database, I can explain a little about it and speculate
about what's going on in the program.
All prefixes in the database have both a start and end date. All callsigns in
the database have a start date only. DX4WIN uses these dates to determine what
DXCC entity a particular callsign is mapped to. Consider this hypothetical
example:
KC6 (prefix) -> V6 (Micronesia)
KC6JR -> KC6 (Belau) starting 01/01/1994
KC6JR -> V6 (Micronesia) starting 01/01/1995
The prefix mapping says that by default, any call prefixed by KC6 will be
mapped to Micronesia. This is the default, if no other callsign mapping
overrides things. In the example above, any QSO made with KC6JR on 1 January
1995 or later will count as V6 (Micronesia). Any QSO made with KC6JR between 1
January 1994 and 31 December 1994 (inclusive) will count as KC6 (Belau). Any
QSO made with KC6JR before 1 January 1994 will count as V6 (Micronesia), based
on the prefix mapping.
Now let's say KC6JR was re-assigned to a ham on Belau starting 4 July 1997.
When you log this call in real-time, the default prefix will be V6, because of
the callsign start date above. Now you change the prefix field from V6 to KC6.
This creates a "temporary" callsign mapping of KC6JR -> KC6 starting *today*
(i.e. in real time). Now you go to the date field and change it to 10 October
1997 (the date of your QSO). However, the callsign mappings in effect at this
time are:
KC6JR -> KC6 (Belau) starting 01/01/1994
KC6JR -> V6 (Micronesia) starting 01/01/1995
KC6JR -> KC6 (Belau) starting 11/08/2003 (August 11)
So the prefix field will reset back to V6 which is NOT what you want.
However, I think the program is working correctly. When you change a QSO date,
DX4WIN will rescan the call/prefix for that date and determine the correct
entity. When you override the prefix, you create a new "temporary" callsign
mapping of KC6JR -> KC6 starting with that date you just entered (10 October
1997). When you save the QSO, the desired mapping will be saved as well.
Note that the date is *not* when the callsign -> country mapping took effect.
In general, you won't know the exact date, unless it's printed somewhere on
your QSL card, or you ask the operator. This is one of the big jobs I have in
maintaining the callsign mapping database. I have a number of logs showing when
people worked certain stations, but that's not always the real starting date.
Someone whose log *does* have that QSO on the starting date may find that the
callsign is mapped incorrectly. This is where my research starts, i.e. trying
to identify the actual start dates for the calls listed in the database.
In terms of a solution to Ken's original problem, you're doing the best you can
do, but you can save yourself a step: enter the call, enter the date, *then*
change the prefix if necessary.
73 - Jim AD1C
--- Lars SM4WGB <[EMAIL PROTECTED]> wrote:
>
> Hallo Ken
> I think it has to be like this because the program goes to the country
> database and checks the prefix in the call in connection with the date. In
> the database there are some prefixes that has been valid for a specific
> country during a certain time period. So this is how it has to be.
> Couldn´t you just add JA to the call to indicate that it is portable JA?
> Like JA/W9XYZ. I think that is how it is expected to be.
> 73s de Lars / SM4WGB
>
> >I'm about half-way through manual entry of about 12K QSO's.
> >
> >When I enter a "portable" call like W9XYZ into the "Callsign"
> >field (not W9XYZ/JA) and enter "JA" in the "Prefix" field all
> >goes well until I enter a new date and tab to the "time" field.
> >At this point the "Prefix" field reverts from "JA" back to "K"
> >and I have to go back and re-enter JA in the "Prefix" field.
> >The entry goes OK after re-entering JA in the "Prefix" field.
> >
> >The above is only true -if- the "Date" is new. Tabbing through
> >the date if the date is unchanged from the previous entry does
> >not cause the "Prefix" field to revert to the prefix for the "Callsign"
> >entry.
> >
> >Is this "normal"? I'm using Ver. 6.02
> >
> >73! Ken Kopp - K0PP
> >[EMAIL PROTECTED]
> >or
> >[EMAIL PROTECTED]
=====
Jim Reisert AD1C, 7 Charlemont Court, North Chelmsford, MA 01863
USA +978-251-9933, <[EMAIL PROTECTED]>, http://www.ad1c.com
PGP Fingerprint: D8E2 3D78 339F A7F1 8C13 1193 B5D1 4FB6 79D1 70DC
