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