I think I may have a better idea what is going on. After leaving the migration going (using the latest gmime) the dbmail-util core dumped again.
I ran dbmail-util with full logging and I could see what situation was bringing up the foreign key error. Essentially dbmail-util -My gets a list of messages present in the dbmail_messageblks table and then proceeds to convert these, but in my case is failing because there are messages in this table which are not present in the other tables e.g. dbmail_physmessage and so the attempt to place their mimeparts in the dbmail_partlists etc fails the constraints. In fact on my test box the query: SELECT distinct physmessage_id FROM dbmail_messageblks where physmessage_id not in (SELECT id FROM dbmail_physmessage) Gives over 16,000 results whereas the same on my live server and its slave give 0 results. This will of course explain why on my previous attempt deleting these entries from the table kept the migration going and perhaps that the error had nothing to do with gmime. Now I thought that dbmail-util -ay checked for unconnected messages and removed them which is clearly not happening on my test box; but at this stage I am also rather perplexed as to how these entries are in the database at all given they are not on the live / slave systems. Daniel Schütze _______________________________________________ DBmail mailing list DBmail@dbmail.org http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail
