Thanks,
The content is indeed only one line. Currently it's "619", giving my next ticket an ID of 2000619 (I guess). I can try, just raising the number in the ticketcounter.log. I was just worried about doing so without consulting this list first about the issue, hence my first post. I'll see if I can test a bit in the morning. Thanks so far. -- /Sune T. From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Gerald Young Sent: 30. november 2010 23:37 To: User questions and discussions about OTRS. Subject: Re: [otrs] Autoincrement trouble Thank you for your comment. Changing the subject slightly, there seems to be no inherent reason why TicketCounter.log should have reset. Given this, and the fact that AutoIncrement uses that to get the *next* number ... What is the content of TicketCounter.log? (It seems as if it should be one line...) Would you be opposed to backing it up (cp TicketCounter.log TicketCounter.log.old) and changing the number in TicketCounter.log to a 6 digit number to test? (Because the worse that could happen is a ticket can't be created for this trial, or a different number is used...) or ... what about the permissions on TicketCounter.log? what if it couldn't be written to? On Tue, Nov 30, 2010 at 5:12 PM, Sune T. Tougaard <s...@lyngsoesystems.com> wrote: Hi Gerald, Improper or not, I appreciate you taking your time to actually present a suggestion. I'm not sure I'm ready to mess directly with the database like that anyways, but thanks for the thoughts. If it is potentially dangerous, I hope others will see your second message as well. My system ID is "20", as you may have guessed. The minimal ticket counter size is still at the default of 5, giving my very first ticket the ID of "2000001". What has happened now, seems to be that after 299999 tickets (ticket id 20299999), it has gone back to 2000001, instead of going to 20300000 as supposed to. And the TicketCounter.log (in var/log) has also started from the beginning. The ticket IDs I'm referring to, are those I can see in the otrs interface. Not those used in the database, if there are differences there. And the IDs it is trying to create, according to the log, just doesn't make any sense (to me). Except perhaps for the 20300017 (which I guess should be the way to go), but that shouldn't exist already. Why the ticketcounter.log has been reset, I do not know. I see know indications in the logs of this. I'm running 2.4.7 on a Windows 2008 R2 server, if that makes any difference. Thanks for inputs so far. -- /Sune T. From: otrs-boun...@otrs.org [mailto:otrs-boun...@otrs.org] On Behalf Of Gerald Young Sent: 30. november 2010 21:56 To: User questions and discussions about OTRS. Subject: Re: [otrs] Autoincrement trouble I wish I didn't post that before. It's very wrong to do and I'd like to take it back. It would have been better to check the AutoIncrement code first. Even if the concept was correct, it's never a good idea to mass update like that as it could affect ticket_history somehow. However, I thought it was reasonable to consider because the ticket number (if I read the schema properly) really only mattered in the ticket table. The problem will come when an email response to an existing ticket isn't properly handled and possibly (?) creates a new ticket. As long as/if AutoIncrement treats the ticket number as identical no matter how many leading zeros, this probably shouldn't be a problem. Of course, I should have tested, first. It was improper to present that as a suggestion on this type of list, and I regret posting it, even if it could help. Respectfully, -- Gerald Young --------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
--------------------------------------------------------------------- OTRS mailing list: otrs - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/otrs To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
