I will try doing the upgrade without touching the ArticleSearchIndex and IndexAccelerator settings for now. Hopefully that can give me a clue to where the problem is. Thanks. -- /Sune T. From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Sune T. Tougaard Sent: 26. maj 2010 08:07 To: User questions and discussions about OTRS. Subject: Re: [otrs] Deleting tickets after switching from runtimedb to sta ticdb Thanks Nils, I'm running on a Windows install, so i can't follow it to the letter, but the database upgrade and migration scripts have certainly been executed. Also, I'm not sure whether running the migration script as the OTRS user really matters on a Windows installation. These have been run as Administrator one of the times and the otrs user the other. Thanks for any further input you can send my direction. -- /Sune T. From: otrs-bounces@otrs.org [mailto:otrs-bounces@otrs.org] On Behalf Of Nils Leideck - ITSM Sent: 26. maj 2010 03:09 To: User questions and discussions about OTRS. Subject: Re: [otrs] Deleting tickets after switching from runtimedb to staticdb Hi, On 25.05.2010, at 02:05, Sune T. Tougaard wrote: I've been doing some upgrade tests on our OTRS installation, currently running 2.2.4. After upgrade to 2.4.7, and running the "Support Assessment" I noticed that the ArticleSearchIndex and IndexAccelerator should be set to "StaticDB". I did, and rebuilt the indexes as mentioned in the documentation. However, after doing this, it appears that one of the cron jobs starts to bulk-delete a lot of tickets in the database. Since this is an upgrade and I'm trying to cover my behind, I'm a bit unsure whether it's a problem with the existing generic agents for example, or if it's supposed to behave like that after switching to "StaticDB". Late last week, I did another test-upgrade and the log file have grown to 11mb over the weekend. Some of the entries that I'm worried about looks like this: [Mon May 24 05:44:39 2010][Notice][Kernel::System::GenericAgent::_JobRunTicket] Delete Ticket (2081000/80575). There are many many entries like this with different ticket IDs of course. I do have a few generic agents that does some delete actions, but certainly not to fill the log to 11mb. Also, SQL'ing my way in the original installation to the tickets being deleted, shows that the tickets are definitely not among those I'd like the generic agents to handle. Later in the log a substantial amount of these shows up: [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (85224)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::IndexAccelerator::StaticDB::TicketLockA cceleratorAdd][213] Need TicketID! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (83884)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (83884)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (83884)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (83884)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (83884)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::HistoryAdd][6265] Column 'queue_id' cannot be null, SQL: 'INSERT INTO ticket_history (name, history_type_id, ticket_id, article_id, queue_id, owner_id, priority_id, state_id, type_id, valid_id, create_time, create_by, change_time, change_by) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, current_timestamp, ?, current_timestamp, ?)' [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (83884)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::IndexAccelerator::StaticDB::TicketLockA cceleratorAdd][213] Need TicketID! [Mon May 24 05:57:22 2010][Error][Kernel::System::Ticket::TicketGet][997] No such TicketID (83884)! [Mon May 24 05:57:22 2010][Error][Kernel::System::Queue::QueueGet][751] Need ID or Name! [Mon May 24 05:57:22 2010][Notice][Kernel::System::GenericAgent::_JobRunTicket] Delete Ticket (2085527/83884). Also with different ticket IDs. Can anyone shed some light on this? I've postponed my update twice, because I started seeing this behavior and I'd really like to get 2.4.7 rolling, as there are many improvements we'd like to get our hands on. If you say this is normal after switching to StaticDB after having used RunTimeDB for quite a while, I can calm a bit down and go forward. Thanks a lot for your input. Did you follow strictly the UPGRADE processes as written in the file UPGRADE ? Freundliche Grüße / Kind regards Nils Leideck -- Nils Leideck Senior Consultant nils.leideck@leidex.net mailto:nils.leideck@leidex.net nils.leideck@otrs.com mailto:nils.leideck@otrs.com http://webint.cryptonode.de http://webint.cryptonode.de / a Fractal project