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
toggle quoted message
Show quoted text
-----Original Message-----
From: Dave Bernstein [mailto:dhb@...]
Sent: Thursday, March 22, 2001 3:20 AM
To: dxlab@...
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@...
Your use of Yahoo! Groups is subject to
