Summary: | `accountlines.accountno` is SMALL-INT, and maxs too quickly | ||
---|---|---|---|
Product: | Koha | Reporter: | Chris Cormack <chris> |
Component: | Database | Assignee: | Galen Charlton <gmcharlt> |
Status: | CLOSED INVALID | QA Contact: | |
Severity: | normal | ||
Priority: | P5 - low | CC: | fred.pierre, wizzyrea |
Version: | rel_3_0 | ||
Hardware: | PC | ||
OS: | All | ||
Change sponsored?: | --- | Patch complexity: | --- |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: | Version(s) released in: |
Description
Chris Cormack
2010-05-21 01:07:15 UTC
actually you might have been on to something: we just found that a writeoff was grabbing the max accountno *from the whole table* and incrementing that. It certainly is possible to max it, in those conditions (we did, I have proof). (the bug in the above comment was fixed with the application of the patch for bug 3498 - but that may be why you were having the feeling that it was maxing quickly) Updating to Koha 3.6 will prevent future problems, but libraries where patrons already have several accountlines with accountno 32767 (due to previous Koha writeoff bug) may still experience problems. At our library we currently have more than 319,000 accountlines set to accountno 32767! When making a payment, several lines may disappear from the pay fines table, because the process intended to act on one line, actually affects all lines with accountno 32767. Jorge is authoring a cleanup script that will rewrite accountlines for each patron with sequential accountno's starting at 1. That will reset all 32767 lines to proper sequential values. Will post as soon as it's ready! |