Hi List, Last night, our system (2.4.7) running "AutoIncrement" on the ticket number sequence generation, crossed over from 20299999 to 20300000 (or so it seems). But apparently something went wrong, and now it has gone back to 2000001 after having had a few issues with determining which number to use. The log looks like this: [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (2000001) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (2000001) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (2000001) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (2000001) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (20100013) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (20100015) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (20100013) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (20100013) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (2000003) exists! Creating a new one. [Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreat eNumber] Tn (20300017) exists! Creating a new one. Please note the ticketnumbers, some are 5 and some are 6, some have a 1, some have a 3. Now it seems to have settled for only 5 beginning from 1, going upwards. TicketCounter.log seems to agree with this. Any ideas what might have gone wrong and how I get out of it again? I could just let it run, spamming the log with the above messages, until it finds free numbers again, but I'm not sure what the consequenses will be. Increase the number in ticketcounter.log, perhaps? Switch to "Date" or something?! Any input will be much appreciated. Thanks -- /Sune T.
Note: I wrote all this before looking at the code. The code seems like it
should handle this properly, but in the mean time, this is what I wrote, in
case it makes sense or something. No guarantees. It doesn't seem to have
been necessary.
===Begin===
Is your ticket length "5"? You may want to increase that in sysconfig.
Ticket::NumberGenerator::MinCounterSize:
If "AutoIncrement" was selected as TicketNumberGenerator you can set the
minimal ticket counter size. Default is 5, this means the counter starts
from 10000.
It also means that 5 digits is all that's significant in your particular
numbering scheme.
the "1" is a "carry" and ignored, which is why you're generating duplicates.
Changing n=5 to 6, 7, 8, 10, won't help, on its own, though, because you
have established tickets with numbers and the system may be treating the
first 2 numbers (20?) as site ID. Whatever number you choose will be the
limit of tickets (10^(n+1)) until this happens again.
I believe you'll also need to adjust all your existing tickets to 20*000*#####
(number of zeros to insert is n-5, except for the tickets that already have
20*1*#####, -> 20*00*1#####, or n-6).
Something like
UPDATE ticket SET tn=tn - 2000000 + 20*0000000 *WHERE tn < 2100000;
UPDATE ticket SET tn=tn - 20000000 + 20*0000000* WHERE tn < 21000000;
This removes the leading "20" from the entry, and adds the appropriate
number of zeros after it.
The number of *bold *zeros (or zeros following the second "20") should be
"n".
Your results may vary. Backup your database before doing such things as mass
updates. See if what I said makes sense before doing it, and ask a question.
:) I could be wrong, but based upon what you've said, this might be what
happened.
===END===
As I mentioned above, the code seems to handle this, because it's thinks of
"minimum" up to minimum+5 digits.
I haven't spent a lot of time looking at
Kernel/System/Ticket/Number/AutoIncrement.pm but I was hoping someone else
might have spoken before I posted this. Please backup and test before making
this live.
I hope it helps. Please ask a question if you don't understand.
--
Gerald Young
On Fri, Nov 26, 2010 at 4:37 AM, Sune T. Tougaard
Hi List,
Last night, our system (2.4.7) running “AutoIncrement” on the ticket number sequence generation, crossed over from 20299999 to 20300000 (or so it seems).
But apparently something went wrong, and now it has gone back to 2000001 after having had a few issues with determining which number to use. The log looks like this:
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (2000001) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (2000001) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (2000001) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (2000001) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (20*1*00013) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (20*1*00015) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (20*1*00013) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (20*1*00013) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (2000003) exists! Creating a new one.
[Thu Nov 25 23:54:06 2010][Notice][Kernel::System::Ticket::Number::AutoIncrement::TicketCreateNumber] Tn (20*3*00017) exists! Creating a new one.
Please note the ticketnumbers, some are 5 and some are 6, some have a 1, some have a 3.
Now it seems to have settled for only 5 beginning from 1, going upwards.
TicketCounter.log seems to agree with this.
Any ideas what might have gone wrong and how I get out of it again?
I could just let it run, spamming the log with the above messages, until it finds free numbers again, but I’m not sure what the consequenses will be.
Increase the number in ticketcounter.log, perhaps?
Switch to “Date” or something?!
Any input will be much appreciated.
Thanks
--
/Sune T.
--------------------------------------------------------------------- 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
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
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-bounces@otrs.org [mailto:otrs-bounces@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
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
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-bounces@otrs.org [mailto:otrs-bounces@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
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-bounces@otrs.org [mailto:otrs-bounces@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
participants (2)
-
Gerald Young -
Sune T. Tougaard