Fix for Clublog upload problem

2 posts / 0 new
Last post
4X6GP
Fix for Clublog upload problem

I was experiencing a problem when doing real-time Clublog uploads: if a QSO was rejected because the call format was unacceptable, then the program would get stuck and be unable to continue uploading. It would attempt to delete the QSO, but the QSO would not be found in Clublog. It would continue to try to delete the same nonexistent QSO every time a new QSO was entered.
This was because the program was treating both the original failure to accept the QSO and the subsequent failures to delete it as fatal errors which needed to be retried. A better behavior would be to ignore them.
I made three changes to the section of the function GetResultMessage in module dmLogUpdate that deals with parsing the result of a clublog upload attempt. Here is the code snippet; I commented the changes with my call:


upClubLog : begin
case ResultCode of
200 : Result := 'OK';
400 : begin // insert QSO rejected
Result := Response;
FatalError := False // 4x6gp
// if (Pos('skipping qso',LowerCase(Response))=0) then //consider skiping QSO as non fatal error, the app can live with it :)
// FatalError := True
end;
403 : begin
Result := 'Access denied'; // deletion failed
// FatalError := True
FatalError := False // 4x6gp
end;
500 : begin
Result := 'Internal error';
FatalError := True
end;
404 : begin // deletion failed
Result := Response;
// FatalError := True
FatalError := False // 4x6gp
end
end //case
end;

Apology: the forum software removed the leading spaces/tabs and I couldn't get it to not do that! So it is hard to read. But you can see the changes that I made.

Now the bad behavior doesn't occur. I haven't noticed any downsides yet.
Victor, 4X6GP

n1kx
Re: Fix for Clublog upload problem

I have had the same issue, but have managed it so far by simply deleting the offending entry from the log_changes table manually. I like the solution proposed.

The other semi-related issue is, if I receive and enter any QSLs (or any other changes) for contacts made with my previous callsign I'm unable to have those changes uploaded to ClubLog automatically, but have to export an ADIF and upload it manually. I assume this is due to the way the upload is triggered at ClubLog, negotiating a transaction using the current callsign being used in CQRLog which doesn't match the callsign being uploaded. This also causes a fatal error that I believe will be caught and handled successfully by your changes. I have not yet looked into the way uploads are managed between CQRLog and Clublog to try to create a proposed solution for this other issue, but I hope to do that soon.