Editing a QSO doesn't stick until the 2nd time

[k3gx]

I have RUMlogNG v5.7 running on MacOS 11.6.4 and have an annoying problem where when I edit a QSO, the popup window comes up, I make the changes, and then hit save - but the changes do not get saved until I open the contact up a second time, make the changes, and hit save again. Am I doing something wrong when editing?

Thanks,
Dave K3GX

[DL2RUM]

Do you edit one or multiple QSOs?
Which field was changed?

[k3gx]

This happens when I edit one contact at a time. Yesterday, I was editing multiple fields in each QSO including location (city), grid square, and comments. When working SOTA, I like to edit the city to refer to the peak name, the grid square to the grid location of the peak, and put the point value in the comments field. I found that even just editing one of the user-defined fields, such as the SOTA reference, resulted in the same behavior.

Thanks,
Dave K3GX

[DL2RUM]

One more:
Do you use the iCloud synced logbook?

Most probably the changed data are saved correct, but are shown wrong in the log table.

[k3gx]

Good point. Yes, I do store on iCloud. Does it take time for the entry to update when doing that?

[DL2RUM]

No, it takes affect right away. All data are stored locally first.
When you observe it again, quit RULog and restart it. Check again. This helps me trouble shooting since I can't duplicate the failure.

[N7YHF]

I have the same issue--editing a single QSO requires two attempts about 80% of the time. I am most often changing the grid locator when WSJT-X doesn't populate it correctly. My logbook is an iCloud-synced one.

I am using RumLogNG 5.10 (544) on macOS 12.6.

[DL2RUM]

Tab out of the field before you save the changes. When the changes are not seen, restart RL. Are the changes now visible?

[shadow]

I really enjoy using RumLogNG, it's a fantastic piece of software.

I have a similar issue however, sometimes it takes more than twice to edit the QSO. I've also noticed that if I'm scrolling the list of QSOs that it jumps / resets periodically. I stopped using iCloud syncing and both behaviors stopped.

I'm wondering if the iCloud syncing is happening in the background when the QSO is open, maybe a database locking issue?

--Marc

[KC3TCT]

Hello.

I had originally set up to use the iCloud synced log but, somewhere along the way, switched to a local file. This past week, I had switched back to the synced log and had the same issue. I noticed that imports from WSJTX and FLdigi seemed to appear quicker but I would have to edit the info twice before the changes showed. I exported the log to a local file (in the iCloud directory) and the issue went away.

Cheers and 73,
Jim KC3TCT