开云体育

Yes, of course I saw that too and Logger is a bit flaky on that score because it doesn't have separate fields for name and QTH and the exports the comment field with the <NAME> tag. I could see what

The progress problem is a defect that was easily fixed; I'll send you a progress report file so youc an verify that this was the only problem. I noticed a lot of "truncated name" messages. With the

Dave, The import went fine, except for the program error that occurs at QSO #3757. I found that all I have to do to recover from that is to close and reopen DXKeeper, then start the import again.

That's a pretty good clue, Rich -- it implies that the import operation is not properly handling worked-but-not-confirmed QSOs. I've imported my 13K QSOs (from the first-generation DXLab, which began

Dave, I am still having a problem with the Progress Table not showing correct results for imported log entries. I did a little more research and found that the only entries that were appearing in the

DXKeeper 1.1.6 corrects a defect that prevents addition of the first QSO to a log via the Capture Window. This release also includes further improvements to the online help. If you've already

Along with the DXCC database support described below, this release also includes updated online help, which is accessible via http://www.qsl.net/dxkeeper/Help/index.htm . If you've installed

I should have a new version of DXKeeper ready tonite -- it doesn't use DXView during imports, and thus should eliminate the performance problem. Then we can determine whether there is an additional

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

OK, a bunch of stuff here. First I have succeeded in getting the import to work with DXView. Here is what I did: 1) Closed all applications and closed my dial up connection. 2) Disabled Norton

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

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

The primary purpose of this release is to correct the defect in Hygain DCU rotator support reported by Julio below. I learned from Ed at DataMatrix (the developers of ProLog) that the "set bearing"

I import more than 1000 qso's from logger with out problems -----Oorspronkelijk bericht----- Verzonden: woensdag 21 maart 2001 23:50 Aan: dxlab@... Onderwerp: RE: [dxlab] Re: Progress

Our man Kurt, OE1002419, noticed that both the FR and LZ callbook URLs had changed, tracked down the new URLs, and sent them my way. So we have him to thank for the updated Pathfinder searches now

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

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

Yes, if there's a country code present in the imported QSO, DXKeeper respects it. The procedure you suggest will result in each imported callsign being checked by DXView to determine a country

I'm not sure if DXView was open when I did the import. However, it was open when I did the recompute. I just did that again to make sure, it didn't help. However, I just noticed something else. When I

Without seeing your log, I can't know for sure, but my suspicion is that many of your DXKeeper log entries are missing DXCC country codess -- likely because DXView was not running when these entries