Inmiddels mag het (bijna?) wel standaard procedure worden: zodra er met een opschoonfunktie records uit de database worden verwijderd, dan mag daarbij niet op een formele wijze het record op een andere plek in de index worden geplaatst.
Op zich zijn de meeste opschoonruns zodanig opgezet dat ze in staat zijn om gedurende de dag records uit de database te kunnen verwijderen, opdat de tabel daarna op een ander (beter geschikt) moment kan worden gereorganiseerd.
LOLROS is nu de 2e funktie waarbij a.g.v. dit opschonen en het op een formele wijze verwijderen van records, de indexfile zodanig explosief groeit, dat het de opschoonrun is die foutloopt vanwege het feit dat die index tijdens het opschonen boven de 2 GB uit komt.
LOLR wordt derhalve m.i.v. heden op een minder formele manier opgeschoond, en vereist dat er daarna direkt gereorganiseerd wordt.
Nb: Merk op dat de mate waarin e.e.a. foutloopt ook door de gebruiker zelf beinvloed kan worden. Stel dat je 5 jaar data aan boord hebt, en je gaat daar 4 jaar uithalen, dan zal van 4/5 deel van alle records de indexensleutel worden gewijzigd, en is het op zich wel verklaarbaar dat dat ellende oplevert. Beter is dus om het opschonen in etappes te doen, bijvoorbeeld van een jaar.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOLROS | Omschrijving (nog) niet bekend | 27-10-2010 | 03-11-2010 |
