Would it be less dangerous to use the SQL to local the records but instead of insert into old.issues replace the NULL value with a patron record that you created for this purpose - I'd suggest a patron type with no fies :-)? That way if you had the items in hand you could check them in, staff could look for the items on the shelves to check in any that are already shelved and you'd then know what items where still checked out. The normal check in would correct any that were returned by patrons later.<br>
<br>something like:<br>mysql> update issues set borrowernumber = (your dummy patrons id) where borrowernumber is NULL;<br><br>Mark (at LibLime) used this to fix records for us that had NULL borrowers. <br>
<br clear="all">Susan Bennett<br>ILS System Administrator<br>Geauga County Public Library<br>440 286-6811 x 125<br>440 286-7419 FAX<br>
<br><br><div class="gmail_quote">On Thu, May 7, 2009 at 4:28 PM, Galen Charlton <span dir="ltr"><<a href="mailto:galen.charlton@liblime.com" target="_blank">galen.charlton@liblime.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi Rachel,<br>
<br>
2009/5/7 Rachel Hollis <<a href="mailto:Rachel.Hollis@stevenshenager.edu" target="_blank">Rachel.Hollis@stevenshenager.edu</a>>:<br>
<div>> 4. Affected items checked-in are “not checked out” - they cannot be returned<br>
> so are forever overdue? is this because they are separated from patron data?<br>
<br>
</div>Yes. There is a way to get rid of them, which will require use of<br>
SQL. With this sort of SQL update, it a good idea (nay, required!) to<br>
do a complete backup beforehand, perform the update outside of normal<br>
library hours, check the results right away, and be prepared to<br>
restore from backup.<br>
<br>
The process would looks like this:<br>
<br>
1. Do your backup.<br>
<br>
2. Find out exactly how many loans are now ghosts:<br>
<br>
SELECT COUNT(*)<br>
FROM issues<br>
WHERE borrowernumber IS NULL;<br>
<br>
2. Copy those loans that were incorrectly anonymized to the issue<br>
history table using the following SQL:<br>
<br>
INSERT INTO old_issues<br>
SELECT * FROM issues<br>
WHERE borrowernumber IS NULL;<br>
<br>
3. Actually delete those ghost loans:<br>
<br>
DELETE FROM issues<br>
WHERE borrowernumber IS NULL;<br>
<br>
4. Clear the item record's copy of the due date:<br>
<br>
UPDATE items<br>
SET onloan = null<br>
WHERE itemnumber NOT IN (SELECT itemnumber FROM issues);<br>
<br>
After you do this, those items will no longer be on loan. Because of<br>
how Koha stores item information, and specifically the due date, you<br>
may see a couple spots, probably in search results, where it appears<br>
that the item still has a due date, but that won't prevent the item<br>
from circulating.<br>
<br>
This procedure will *most likely* allow these items to be circulated<br>
again, although without a backup it is impossible to restore the<br>
original borrowernumbers. Although I try not to overburden messages<br>
with disclaimers, one definitely applies here: although I am happy to<br>
answer further questions, actually running the update you would do at<br>
your own risk - please be sure that your are certain that you can<br>
backup and restore your database before trying this.<br>
<br>
A fix for the underlying bug (null borrower numbers in the issues<br>
table) is being worked on.<br>
<br>
Regards,<br>
<br>
Galen<br>
--<br>
Galen Charlton<br>
VP, Research & Development, LibLime<br>
<font color="#888888"><a href="mailto:galen.charlton@liblime.com" target="_blank">galen.charlton@liblime.com</a><br>
p: 1-888-564-2457 x709<br>
skype: gmcharlt<br>
_______________________________________________<br>
Koha mailing list<br>
<a href="mailto:Koha@lists.katipo.co.nz" target="_blank">Koha@lists.katipo.co.nz</a><br>
<a href="http://lists.katipo.co.nz/mailman/listinfo/koha" target="_blank">http://lists.katipo.co.nz/mailman/listinfo/koha</a><br>
</font></blockquote></div><br>