True Jack, there can be a lot of individual choices in mapping. But it seems to me that Joe Glockner's update exe's make the needed updates (most of them) yet do not disturb the individual special cases.
Just running Joe's updates have been very helpful. Then there are the country file updates used by contest programs provided by Jim Reisert AD1C: http://www.country-files.com/cty/ http://dx4win.ad1c.us/ Notice that he provides a file to update DX4Win, perhaps he would do the same for DXBase2007. Or perhaps DXBase could use one of the existing country files. I realize there is no perfect solution in such a dynamic environment. Ron, N5IN ________________________________ From: Jack <[email protected]> To: Neal Campbell <[email protected]>; [email protected] Cc: [email protected] Sent: Saturday, October 3, 2009 1:46:50 PM Subject: Re: [Dxbase] suggestion A little history about this: In the beginning, let's say about 15 years or so ago, the first version of DXbase was released with no means for users to modify the prefix tables... feedback was that the user needed to be able to do this..... so, thus was born the capability for users to modify the prefix databases.. DXbase was one of the first and only software products that allowed users to have complete control over prefixes. Life was good, but then the feedback switched to .... why can't we just download the updates ... Life wasn't so good for some... So, over time the prefix databases became so good that it was usually only when the ARRL or other entity changed things that any prefix work was necessary except it was sort of typical that just before a DXpedition or contest, some strange prefixes would show up requiring some prefix mapping... in these instances users could make the change themselves or lucky for all someone like Joe made some tools available.. Bottom line is that no matter what you decide, you will please some and get complaints from others.... the refdata is the repository for not only prefix related stuff but also manager stuff ... If you opted for removing user updates for prefixes, I'd give some consideration to separating out the manager stuff into its own database and perhaps some means to import manager stuff from some master without users losing their own stuff. Perhaps even some means for users to upload their stuff and allow the master to somehow extract any new or changed stuff. I guess the scenario that would be a problem is when something new pops up on the bands which is not recognized. At that instant and until the "master" was available and downloaded, the user might be stuck with packet spots that were't properly recognized, or possibly couldn't log properly. Of course, there are users who are not very savy when it comes to downloading, copy/pasting, etc.... so for them, this will generate some support needs but probably no worse than it is with the current methodology. Sorry to ramble... just some thoughts.... Cheers, ----- Original Message ----- From: "Neal Campbell" <[email protected]> To: <[email protected]> Cc: <[email protected]> Sent: Saturday, October 03, 2009 1:19 PM Subject: Re: [Dxbase] suggestion >I can certainly accept that (its supposed to be another form of > communication, not a means to stop it!) > > I want your feedback on:discuss is the reference data. DXBase uses the > Jet > database engine (commonly called Access) for data storage. DXBase gives > you > the functionality to modify ref data and those who own a copy of MS Access > 98 (the version that is compatible with the current version of DXBase) can > do even more creative things with the reference data (add new fields. > etc.) > Thia is a real luxury that no other logging program I am aware offers > (since > most of the data access logic is proprietary or you are never informed > what > system tools you could use to modify things). > > As with most things in life, this luxury comes with a cost and a > responsibility. I am a big believer in making updates an automatic > function > (if you enable the automatic update function in a preference). So, when > new > prefixes, countries, qsl mgrs, program updates, etc.) would be downloaded > from my server and applied. Hopefully, this sounds good to you! However, > the > only real way to do this without incredible complexity is to backup the > old > data tables, replace them with the new tables then pro grammatically > re-initialize the new tables. This means that any of you who have manually > manipulated these tables will lose those changes. > > So, what is your feeling about this? How many of you are modifying these > tables and what is the nature of the changes? How would you feel if we can > dramatically improve the frequency/turnaround/process of updates at the > sacrifice of your ability to add new fields, etc (or at a minimum leave it > to you to figure out how to import that data from the old backup table)? > > 73 > > Neal k3nc > ______________________________________________________________ > 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 ______________________________________________________________ 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
