Yes, multiple databases are to be avoided. I started with the notion
of one DXCC database managed by DXView, with other applications
invoking DXView for callsign lookups, etc. But its unacceptable for
DXKeeper to record QSOs without DXCC prefixes and country codes just
because DXView is either not installed, or installed but not running.
And we see that relying on DXView for batch operations like "import"
significantly reduces performance. Its no problem to have DXKeeper
directly access DXView's database (rather than send a message to
DXView to perform that access on its behalf) -- that eliminates the
performance problem, and the requirement that DXView be running. But
it does require DXView to be installed, which may not be the case. So
providing a duplicate copy of the database with DXKeeper, and
arranging for DXKeeper to automatically use it if DXView isn't
installed solves the problem in a manner that's completely
transparent to the user.
I could make DXKeeper delete its DXCC database if it finds that
DXView is installed; this eliminates any user confusion as to which
database to update (e.g. adding a new DXCC entity) and saves the disk
space. Its only a problem if the user subsequently uninstalls DXView,
but this could be corrected by downloading a DXCC database from the
DXKeeper web site.
toggle quoted message
Show quoted text
--- In dxlab@y..., "Richard B Drake" <rich@w...> wrote:
Wow, that is a bit complex but it sounds like you have a good
handle on it. The problem of keeping two copies of a database in
sync without requiring data to be entered in two places is always
a bit tricky. I take it from this that when DXView is installed it
is the master, DXKeeper is the slave and one should never directly
update DXkeeper (assuming that there will eventually be a tool to
do it). You sure are fast at this stuff!!
----
73, Rich - W3ZJ
-----Original Message-----
From: Dave Bernstein [mailto:dhb@m...]
Sent: Thursday, March 22, 2001 3:20 AM
To: dxlab@y...
Subject: [dxlab] Re: Progress window
To ensure its ability to perform callsign lookups,
DXKeeper will from
now on include a copy of the DXCC database previously
only packaged
with DXView. During startup, DXKeeper will determine
whether DXView
is installed. If so, it will reference DXView's copy of this
database, ignoring its own copy -- this permits a
single point of
database maintenance, e.g. when adding a new DXCC
entity. If DXView
is not installed, then DXView will refer to its own copy of the
database.
Callsign lookups during import operations will directly
reference a
DXCC database, either DXView's (if installed) or
DXKeeper's. DXView
itself will not participate in import operations, which
should speed
things up quite a bit.
For callsign lookups during interactive operations
(such as logging a
QSO), DXKeeper will attempt the callsign lookup via
DXView if its
running; in performing this lookup, DXView updates its
information
display. If DXView is not running, then DXKeeper will
perform the
lookup using its copy of the database.
So import operations run fast and don't depend on (or overload)
DXView, interactive operations use DXView if its
running, but in no
case will DXKeeper create a QSO that's missing DXCC
prefix or country
code information.
There's more complexity here than I'd like, but most of
it is hidden
from the user. If you've installed DXView, then you can
use it to
maintain your DXCC database and DXKeeper will automatically be
consistent. If you aren't using DXView, then DXKeeper
has its own
DXCC database (though you lack a tool to update it, and
thus have to
download updates from DXKeeper web site).
Comments?
The above approach is implemented (in DXView 1.1.5) and
appears to
work, but I'd like to test a few more cases before posting it.
73,
Dave, AA6YQ
--- In dxlab@y..., "Dave, AA6YQ" <dhb@m...> wrote:
Sounds like there's a latent defect in the DDE
connection between
DXKeeper
and DXLab. I suggest you hold off until I release a
version of of
DXKeeper
that performs the country code lookup without
consulting DXView.
Shouldn't
take too long...
73,
Dave, AA6YQ
-----Original Message-----
From: Richard B Drake [mailto:rich@w...]
Sent: Wednesday, March 21, 2001 17:50 PM
To: dxlab@y...
Subject: RE: [dxlab] Re: Progress window
>
> Does this explain the large variance in confirmed
countries you
> mentioned earlier?
>
I don't know, but I am having a great deal of
difficulty with the
import. I took out all the DXCC entries in the ADIF
file to force
a lookup in DXView. It starts off going OK, pretty
slow but I can
live with that. Then it suddenly seems to lose
communication with
DXView and starts flying along without putting in a
DXCC prefix.
The first time I tried it, it only put in about 10
prefixes before
that happened. I tried again and this time it got
to about 400
before it lost the connection. In any case it will
not handle my
5000 entry log in one go. It gets up to QSO# 3762
and dies. I can
handle that by doing it in two pieces but I don't
know what to do
about the loss of communication with DXView.
----
73, Rich - W3ZJ
Yahoo! Groups Sponsor
iWin.com - The Place to Win Stuff!
To unsubscribe from this group, send an email to:
dxlab-unsubscribe@y...
Your use of Yahoo! Groups is subject to the Yahoo! Terms of
Service.
------------------------ Yahoo! Groups Sponsor
To unsubscribe from this group, send an email to:
dxlab-unsubscribe@y...
Your use of Yahoo! Groups is subject to
