Speciaal voor ADS (Advantage Database Server) tabellen zijn er bij Reorganiseren Bestanden een tweetal opties erbij gekomen:
* PACK Uitvoeren J/N
* Reorganiseren specifiek Indexnummer.
Indien een record wordt verwijderd (we verwijderen bijvoorbeeld een Verkooporderregel) dan wordt dit record in werkelijkheid slechts "gemarkeerd" als zijnde verwijderd; dit soort records worden nog niet daadwerkelijk uit de tabel verwijderd. Voor de gebruiker zal het niet veel uitmaken of het record daadwerkelijk verwijderd is of slechts gemarkeerd is als verwijderd; het komt eropneer dat ze het verwijderde record niet meer zal aantreffen.
Bij het reorganiseren wordt normaal gesproken standaard een PACK uitgevoerd, welke deze 'als verwijderd gemarkeerde' records daadwerkelijk uit de tabel verwijderd, en waardoor de diskruimte die door deze verwijderde records in beslag wordt genomen weer vrijkomt.
Dit is erg zinvol als we gelimiteerd zijn aan een maximale grootte van een tabel (bijv. de 2 GB i.g.v. een VFP tabel) en er veel verwijderde records in een tabel zitten.
Intern zal e.d. PACK een nieuwe tabel aanmaken en alleen die records die niet verwijderd zijn overnemen uit de oude tabel. Helemaal als we met grote tabellen werken, zal e.d. PACK tijd in beslag nemen. Zo kan het voorkomen dat als we een tabel LOVR moeten reorganiseren, welke 15 indexen heeft, dit 20 minuten in beslag neemt voor de PACK, en daarna gemiddeld 5 minuten per index. In totaal zijn we dan 20 minuten + (15*5) = 95 minuten kwijt.
Omdat we bij een ADS tabel niet meer gelimiteerd zijn aan de 2 GB limiet voor een tabel, en ervanuitgaande dat het ons eigenlijk niet uitmaakt dat er zoveel 'als verwijderd gemarkeerde records' in een tabel zitten (uitgangspunt is dat het pakket zodanig is opgezet dat het er niet trager op wordt), is de mogelijkheid opgenomen om deze PACK uit te schakelen. In bovengenoemd voorbeeld levert dat 20 minuten winst op, omdat we direkt kunnen beginnen met reorganiseren.
Een tweede optie betreft het kunnen reorganiseren van een specifieke index. Het komt in principe niet vaak voor dat een bestaande index wordt gewijzigd, maar zo af en toe gebeurt het toch wel eens. In de oude situatie moest daardoor de hele tabel opnieuw gereorganiseerd worden. Met de nieuwe optie kunnen we aangeven dat we slechts die ene gewijzigde index opnieuw willen reorganiseren.
Ook in de (veel vaker voorkomende) situatie dat er een index bijkomt zouden we kunnen volstaan met het reorganiseren van alleen de nieuw erbij gekomen index. Dus, stel je voor dat tabel LOVR een 16e index erbij krijgt, dan impliceerde reorganiseren voorheen: 20 minuten voor de PACK + vervolgens 16 indexen maal 5 minuten (= 100 minuten) terwijl we in de nieuwe situatie kunnen volstaan met alleen het opbouwen van de 16e index (waarbij de PACK wordt overgeslagen, en het opbouwen van index 1 t/m 15 ook achterwege blijft).
Nb: Het reorganiseren van een specifieke index is alleen weggelegd voor ADS tabellen (bij VFP tabellen hebben we altijd maar één indexfile waarin alle index tags zijn opgenomen, bij ADS tabellen nemen we iedere index in een separate indexfile op).
Merk overigens op dat zodra er een specifieke index wordt gereorganiseerd, de keuze voor "PACK Uitvoeren J/N" gedisabled wordt op "Nee". Het uitvoeren van een PACK impliceert immers dat alle als verwijderd gemarkeerde records worden verwijderd, daarmee wijzigt dus het aantal records in de tabel, en dat impliceert dat
iedere index verplicht opnieuw moet worden opgebouwd. Een specifieke index reorganiseren gaat derhalve per definitie niet gepaard met een PACK.
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| APPGUGDB | Omschrijving (nog) niet bekend | 26-01-2012 | 27-01-2012 |
| LOBHOI | Reorganiseren Bestanden | 26-01-2012 | 27-01-2012 |
| LOBHOI1 | Opbouwen Indexen. | 30-12-2011 | 30-01-2012 |
| LOBHOIVA | Omschrijving (nog) niet bekend | - - | 27-01-2012 |
| SYBHOIDD | Omschrijving (nog) niet bekend | 26-01-2012 | 27-01-2012 |
| SYBHOIIO | Omschrijving (nog) niet bekend | 29-09-2011 | 27-01-2012 |
| SYINV | Omschrijving (nog) niet bekend | 26-01-2012 | 27-01-2012 |
| SYUGHKU1 | Omschrijving (nog) niet bekend | 26-01-2012 | 27-01-2012 |
| SYUGTPU1 | Omschrijving (nog) niet bekend | 26-01-2012 | 27-01-2012 |
