The ARRL country codes are stored in DXBase. They are in the PREFIX-Pri table, which is in the refdata.mdb file.
Jim N6VH On 10/19/2010 10:34 AM, [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
