开云体育

-----Original Message-----
From: dxlab@... [mailto:dxlab@...]
Sent: Tuesday, March 01, 2016 12:28 PM
To: dxlab@...
Subject: [dxlab] A difficult request to clean up and old problem



There's one thing I'd love to do but honestly I don't know if it's possible or feasible. As you know, I converted my entire log from DX Base format three years ago, and that program has a bizarre way of recording split. Instead of logging RX and TX frequencies in their respective fields, as DXK does, it populates the TX Freq field with the RX freq and puts the TX Freq as the first string in the comments. So if I logged a station that was transmitting on 14.195 and I worked them by transmitting at 14.200, when that QSO was imported into DX Keeper, the entry's RX frequency field would be blank, the TX frequency would be converted to 14.195 and the comment field would begin with the characters 14200.00 (in kHz, not MHz). DX Base for whatever reason uses only the TX Frequency field to record the VFO-A frequency. This makes zero sense but it is what it is.





Is it possible to bulk fix these? Is it even worth considering?

Below are just rambling, random comments, not requests/etc, that may be of interest to those who've imported their logs from other software into DX Keeper.

Per my issue in the OQRS discussion thread, I spent about 4 hours this morning parsing my log for erroneous QSL sent settings. I set all the QSL_SENT requests that had been flagged "N" to nil (empty value), but the real fun one was about 500 QSOs from the spring of 2013 that had the sent flag set to S, but nothing in the sent-via field and no QSL sent or received date. The intention was to identify all of these and, like the first group, set their QSL Sent status to undefined.

The filter I had to use for the latter took a while to build but it finally worked:
(QSO_Begin between #2001-03-01# and #2013-05-21#) and (QSL_SENT_VIA not in ('E','B', 'D')) and (QSL_SENT in ('Y')) and (QSLSDATE = #4000-01-01#) and (QSLRDATE = #4000-01-01#). Then I bulk modified QSL_SENT to nil. I'm assuming that "no value" should be the default state of QSL_SENT and QSL_Rcvd unless deliberately acted upon (I've requested a QSL card or I've answered a QSL request).

I also went through and set correct CONTEST_ID values for every contest Q dating back to the beginning, and everything's backed up to the cloud. I never realized how much erroneous info was in there over the years, and I'm sure there's so much more that remains hidden, awaiting some future attempt to do something.