This would be fine IF the ARRL issued the prefixes. However, they do not. The ARRL only will assign a country number to the country.
ARRL issues NO PREFIES to any country at all. >From the activity after the 'magic date/time' the prefixes are staying the same, just governmental control has changed, thereby the status has changed. Prefixes have stayed the same. Mike K8PTT On 10/19/10 1:34 PM, "[email protected]" <[email protected]> wrote: > > Neal, a couple of comments re your latest on Updater...and maybe Joe has > already mentionned these to you. > > DXBase uses prefixes as "country codes" in the program logic...ARRL primarily > uses the numeric codes, which as far as I know are not present anywhere in > DXBase and can therefore be ignored by DXBase. ARRL DOES use prefix country > codes in printouts/reports/forms purely for reader convenience to identify > countries in a way familiar to the users. in this regard, the Czech rep/Slovak > Rep situation is a good indicator of how to deal with the old/new issue. ARRL > assigned "old" Czechoslovakia an OK1 designator in place of previous OK > designator. OK1 was "linked" to the Czechoslovakia country code replacing OK > in their system. Then Czech Rep was assigned the OK prefix (and OM for Slovak > Rep) along with a new numeric code. > > DXBase could handle prefix codes in a similar way I believe. When the new ARRL > prefix designators come out to replace PJ2 and PJ7 (might be PJ9 and PJ8 for > example...just my guess, need to await ARRL), DXBase could set them up as > primary prefixes with the same data as presently contained in PJ2 and PJ7, and > then recode all pre-10/10/10 qsos to the new designator (edit/replace > function). (Minor problem is the first 4 hours of 10/10/10 each user would > have to change manually later.) Then DXBase would rename PJ2 and PJ7 to their > new official names (assuming ARRL reuses these as they did with OK) (data > wouldn't change), and add PJ4 and PJ6 (assuming that is what ARRL assigns) > with appropriate data. Then go through the prefix mapping to reassign PJ1-0 to > their new primaries as of 10/10/10 and after. Might have to look for any > special PJ call prefix maps as well, or perhaps leave that to the users as > there probably aren't many if any. > > re Bonaire IOTA, don't see the problem. IOTAs are not inserted into the qso > database the way prefixes are, rather they are entered qso by qso by the user. > existing Bonaire qsos with the "old" IOTA number should be left alone; they > keep that number. after 10/10/10 if a user enters a PJ4 qso they would simply > insert the new IOTA number as they normally do. (of course the IOTA database > should be updated by adding the new IOTA in the normal way.) > > I'm not a programmer but all this seems to be doable using existing DXBase > functions (not unlike the example in the manual re VR, VP6 etc), albeit time > consuming...certainly an Updater would be profoundly helpful! > > Hank KF2O > > ______________________________________________________________ > Dxbase mailing list > Home: http://mailman.qth.net/mailman/listinfo/dxbase > Help: http://mailman.qth.net/mmfaq.htm > Post: mailto:[email protected] > > This list hosted by: http://www.qsl.net > Please help support this email list: http://www.qsl.net/donate.html ______________________________________________________________ Dxbase mailing list Home: http://mailman.qth.net/mailman/listinfo/dxbase Help: http://mailman.qth.net/mmfaq.htm Post: mailto:[email protected] This list hosted by: http://www.qsl.net Please help support this email list: http://www.qsl.net/donate.html
