开云体育

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 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

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

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

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

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"

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

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

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

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

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

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

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

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

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, 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.

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

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

If there's no standard for how the information is jammed together, then it will be difficult to satisfy everyone. Sounds like "Import from Logger" should mean "place the contents of the name field

I think the answer that would best satisfy the most people (and certainly me), is place the first word in the name field and every thing else in the comment field. It won't be 100% but it will