Dave –

?

As far as I know, the “best” documentation is at , which is the eQSL FAQ on changing callsigns, where it is indicated that one should “create an ‘attached account’ for the new callsign”.? The DXK documentation also touches on the subject when it comes to attempting to use DXK Locations to filter for record relevant to a particular eQSL nickname.

?

So, for example, on 14 August 2012, my callsign changed from AB1OD to N1EN.

?

I therefore have two logins on eQSL: AB1OD and N1EN.

?

If I want to check eQSL confirmations for AB1OD in DXK, I edit the eQSL login information in DXK to AB1OD, and sync QSLs.

If I want to check eQSL confirmations for N1EN in DXK, I edit the eQSL login information in DXK back to N1EN, and sync QSLs

?

A simple example of the cause of my question is as follows.

?

Assume that I last received eQSL confirmations to AB1OD dated 31 December.

Assume that I last received eQSL confirmations to N1EN dated 20 February.

?

If I simply change my eQSL login to ?AB1OD and sync QSLs, DXK will query eQSL for all eQSLs to AB1OD between 20 February and the present.?? I will miss any eQSLs received between 31 December and 20 February under current DXK behavior.

?

Thus, I end up control-clicking “sync” more frequently than perhaps was intended, to cover those gaps.

?

It looks like the DXK database has a single record/field to hold the date of the most recent eQSL received.

?

I wonder if it would be better to store that information in a separate, small table, tracking most recent eQSL on a by-eQSL-login basis, so that (in my example above) DXK would know to query back to 31 December if I were logging in as AB1OD, but only to 20 February if I were logging in as N1EN.

?

That being said…if I’m the only person that’s asked about this, maybe I’ve missed something OR maybe my situation is unique enough to not merit the change. ??J

?

?