It looks like there are foreign keys on everything (well, on the tables I checked anyways, not 100% of them), so you should be fine just deleting the physmessage.
On Mon, 2006-07-31 at 17:39 -0400, DK wrote: > It says "Binary - do not edit" so I can't realy see what that message is. > However if I decide to delete what else would I have to delete besides > "delete from dbmail_physmessage where id = 1543"? > > > On 7/31/06, Jesse Norell <[EMAIL PROTECTED]> wrote: > > Hello, > > > > Ah, you're probably using MySQL. I looked at the create_tables > > scripts for both (just now) and they create different indexes for the > > dbmail_datefield table. In postgres there is: > > > > CREATE UNIQUE INDEX dbmail_datefield_1 ON > > dbmail_datefield(physmessage_id, id); > > > > That includes the "id" which changes for every row so the problem you > > have would not exist there. But in mysql it is: > > > > UNIQUE (physmessage_id, datefield) > > > > which does not. You might want to get some better (ie. probably Paul's) > > insight into the correct thing to do here, but it sounds like that one > > message is partially/incorrectly cached. You could take a look at that > > specific message (select * from dbmail_messageblks where physmessage_id > > = 1543) and see if it would be ok to just delete it (delete from > > dbmail_physmessage where id = 1543). > > > > > > > > > > On Mon, 2006-07-31 at 17:05 -0400, DK wrote: > > > Hi Jesse, > > > > > > Here is what I get: > > > --------------------- > > > physmessage_id id datefield > > > 1543 225 1970-01-01 00:00:00 > > > > > > select last_value from dbmail_datefield_idnr_seq; > > > #1146 - Table 'dbmail.dbmail_datefield_idnr_seq' doesn't exist > > > > > > select max(id) from dbmail_datefield; > > > max(id) = 4634 > > > -------------------- > > > > > > On 7/31/06, Jesse Norell <[EMAIL PROTECTED]> wrote: > > > > Hello, > > > > > > > > Sounds like it's trying to cache the message, which would fix your > > > > issue, but something's not right. What do you get for the following > > > > queries? > > > > > > > > describe dbmail_datefield; > > > > select * from dbmail_datefield where physmessage_id = 1543; > > > > select last_value from dbmail_datefield_idnr_seq; > > > > select max(id) from dbmail_datefield; > > > > > > > > Jesse > > > > > > > > > > > > On Sat, 2006-07-29 at 13:47 -0400, DK wrote: > > > > > So I checked the mail.log on trace level 4 and this is what I am > > > > > getting after running 'dbmail-util -by' seams there is something wrong > > > > > with the date field it says 1970-01-01 which is beginning of Linux > > > > > time. Plus it says something about no Subject field value. What should > > > > > I do? > > > > > > > > > > > > > > > Jul 29 13:39:05 safe dbmail/maintenance[23411]: Error > > > > > dbmysql.c,db_query: [Duplicate entry '1543-1970-01-01 00:00:00' for > > > > > key 2] [INSERT INTO dbmail_datefield (physmessage_id, datefield) > > > > > VALUES (1543,'1970-01-01 00:00:00')] > > > > > Jul 29 13:39:05 safe dbmail/maintenance[23411]: Error > > > > > dbmail-message.c,insert_field_cache: insert datefield failed [INSERT > > > > > INTO dbmail_datefield (physmessage_id, datefield) VALUES > > > > > (1543,'1970-01-01 00:00:00')] > > > > > Jul 29 13:39:05 safe dbmail/maintenance[23411]: Message > > > > > dbmail-message.c,dbmail_message_cache_subjectfield: no subject field > > > > > value [1543] > > > > > > > > > > > > > > > > > > > > On 7/28/06, DK <[EMAIL PROTECTED]> wrote: > > > > > > Well it isn't fixing it > > > > > > > > > > > > On 7/28/06, Jesse Norell <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > When ever I do a "dbmail-util -ya" I get following message. > > > > > > > > > > > > > > > > Repairing DBMAIL for cached header values... > > > > > > > > Ok. Found [1] un-cached physmessages. > > > > > > > > > > > > > > From memory (not using 2.1 yet), isn't it "dbmail-util -by" that > > > > > > > creates the message caches? Maybe try running that. Possibly in > > > > > > > your > > > > > > > previous package upgrade/etc. issues you had stored an email using > > > > > > > dbmail-smtp (or dbmail-lmtp) from version 2.0? That would put it > > > > > > > in the > > > > > > > right format other than the new caching stuff added in 2.1. > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Jesse Norell - [EMAIL PROTECTED] > > > > > > > Kentec Communications, Inc. > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Dbmail mailing list > > > > > > > [email protected] > > > > > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Demi > > > > > > > > > > > > > > > > > > > > -- > > > > Jesse Norell - [EMAIL PROTECTED] > > > > Kentec Communications, Inc. > > > > > > > > _______________________________________________ > > > > Dbmail mailing list > > > > [email protected] > > > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > > > > > > > > > -- > > Jesse Norell - [EMAIL PROTECTED] > > Kentec Communications, Inc. > > > > _______________________________________________ > > Dbmail mailing list > > [email protected] > > https://mailman.fastxs.nl/mailman/listinfo/dbmail > > > > -- Jesse Norell - [EMAIL PROTECTED] Kentec Communications, Inc.
