https://bugs.kde.org/show_bug.cgi?id=362699
--- Comment #2 from Christoph Pospiech <pospiech...@t-online.de> --- I just observed another 5 occurrences of RemoteID = NULL. I did some forensic analysis. Hopefully the following observations help to pin down the problem. 1. Since I am running the akonadi database with my own MySQL server, I could use phpMyAdmin to do some queries, starting from "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" I found that all these entries had a collectionID pointing to the trash can. 2. Apparently they were created by moving entries from an IMAP trash can to the main trash can. The IMAP server was davmail 4.7.1-2416-1, used as an interface to outlook. 3. There were three more entries put to the trash can by Kmail directly - these had a non-NULL RemoteID. 4. Emptying the trash can made the entries with RemoteID = NULL go away (no surprise, given what I said before). 5. I had a more emails in outlook that I could dispose. I repeated the following experiment two times. a. Inside outlook (running in a Win7 VM), put these emails into trash (one or two at a time). b. Wait for davmail to replicate the outlook trash into Kmail. c. Run "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the result. d. Move the emails from IMAP trash to main trash. e. Rerun "SELECT * FROM `pimitemtable` WHERE `remoteId` is NULL;" and note the difference. => One out of three emails disposed that way created a pimitemtable entry with RemoteID = NULL. => This trash can scenario may not be the only one creating this effect. But it is the least dangerous as these emails are to be disposed anyway - so no harm done ! Hope this helps ! Christoph Pospiech -- You are receiving this mail because: You are watching all bug changes.