Advantage Database (Server)
Sinds het begin van Heart-Profit werken alle installaties standaard met de native (Visual) FoxPro Database. Alle data die binnen Profit geregistreerd wordt, wordt opgeslagen in DBF formaat. Hoewel dit formaat voor velen voldoet, is het sinds 2012 ook mogelijk om een andere onderliggende database te gebruiken binnen Profit: een Advantage Database. Bij het gebruik van een Advantage Database Server verandert er weinig aan het uiterlijk van Profit. De data wordt echter niet meer gelezen en geschreven uit DBF tabellen, maar uit ADT files (Advantage Database Table).
Er zijn meerdere redenen om over te stappen op een Advantage Database Server; onderstaand een aantal belangrijke:
* We zijn niet meer gelimiteerd aan de maximale tabelgrootte van 2 GB per DBF (die voor de native FoxPro Database geldt)
* ADS Data Dictionary is beveiligd en kan niet buiten Profit om worden benaderd (als men niet over de juiste inloggegevens beschikt)
* ADS staat naast (normale backups) toe om bijv. ieder uur een backup te maken van alleen de wijzigingen t.o.v. de laatste backup
* Database benaderbaar via SQL
* Performance specifieke funkties die zijn omgebouwd naar rapporteren o.b.v. SQL commando's.
Nb: Aan de overstap naar een Advantage Database Server zijn wel kosten verbonden (denk aan een Fileserver, licentiekosten voor ADS, module voor Profit).
Opschonen i.v.m. 2 GB limiet
De technische beperking van tabelgrootte van 2 GB kan aanleiding zijn geweest om over te stappen op ADS. Op zich is die limiet voor veel klanten geen enkel probleem, en diverse klanten zitten na 20+ jaar nog amper op 25 tot 50% van die limiet. Toch zijn er ook bedrijven die dagelijks dermate veel mutaties hebben dat bepaalde tabellen die limiet gingen overschrijden. Dat effekt kan ook nog versterkt worden doordat een bedrijf andere bedrijven gaat overnemen, en er ineens meerdere administraties in dezelfde database worden verwerkt. Voor de native FoxPro database was het dan 'einde oefening' zodra een tabel de 2 GB limiet overschreed.
In eerste instantie is er toen een oplossing gevonden in het periodiek opschonen van bepaalde tabellen. "Bepaalde tabellen", immers, om boven de 2 GB uit te komen zal een tabel eerst over miljoenen records moeten beschikken; met bijv. een Artikelbestand halen we zoiets niet. In menu 9-5-9-3-1 zijn voor diverse tabellen waarbij de 2 GB limiet aan de orde dreigde te komen opschoonfunkties ontwikkeld:
Inconsistente database
Iedere opschoonfunktie kan hierbij anders werken. 't Liefst zouden we natuurlijk iets zeggen als 'alles t/m datum dd-mm-yyyy mag er uit', maar zoiets is niet mogelijk. Niet mogelijk, bij de gratie dat we niet eenduidig kunnen bepalen welke datum bij welk record van een tabel hoort. Om een voorbeeld te geven: een Verkooporder kan in 2015 zijn toegevoegd, met een Leverdatum in 2016; hoort deze nu bij 2015 of bij 2016? Ook kan de Verkooporder meerdere regels hebben, die ieder weer een andere datum kunnen hebben. Ook kan opschoning nodig zijn in tabellen die geen datum bevatten. Iedereen opschoonfunktie is ontwikkeld conform de specifikaties die aan de orde zijn voor de klant die de behoefte had die tabel op te schonen.
Hoewel ze hierbij zoveel mogelijk heden geprobeerd dit op eenzelfde wijze op te zetten.
Zo geldt bijvoorbeeld dat de opschoonfunkties voor de ordertabellen:
* LOVO - Verkooporders
* LOVR - Verkooporderregels
* LOLL - Raaplijstheaders
* LOLR - Raaplijstregels
* LOCL - Charge-/Leveringen
allemaal worden opgeschoond op basis van een selektie t/m een opgegeven Verkoopordernummer.
Overigens is het bestaan van deze funktionaliteit geen garantie dat u ze klakkeloos kunt gebruiken, alvorens ook maar te denken aan dit opschonen, dit graag eerst overleggen met een consultant van Heart. De diverse opschoonfunkties verwijderen records uit de database, op basis van het Verkoopordernummer. Maar... uitgangspunt daarbij is wel dat U eerst heeft bepaald dat die records er ook wel degelijk uit kunnen! Dus, om een voorbeeld te geven, als u naar "Raadplegen te Leveren Artikelen op Leverdatum' gaat, en ziet dat u nog leveringen open heeft staan op orders uit 2015, dan zullen we niet t/m 2015 mogen opschonen, immers dan worden die produkten nooit meer geleverd. Op eenzelfde manier, als er nog orders zijn die niet gefaktureerd zijn, en U gaat die orders opschonen, impliceert dat dat die faktuur er ook nooit meer uit zal komen! Pas als we met zekerheid kunnen zeggen dat bijv. alle Verkooporders t/m 2010 zijn afgesloten, gefaktureerd zijn, kompleet afgehandeld zijn etc. en we de data kunnen missen als we gaan rapporteren dán kunnen we zeggen dat we alle orders t/m 20109999999 willen opschonen.
Let op: met dat we tabellen gaan opschonen kreëren we per definitie een inconsistente database. Dit alleen al door het feit dat bijv. onze Verkooporderregel-tabel (LOVR) wel kan worden opgeschoond, maar dat we de Verkooporderheader tabel (LOVO) niet hoeven op te schonen; de eerste kan te groot zijn, de 2e nog lang niet...
Backup-/historische filesAls we met bovenstaande tools data opschonen uit tabellen, dan zal er een backup worden gemaakt van de records die verwijderd worden. Alle opschoonfunkties maken eerst een kopie van de struktuur van de op te schonen tabel. Vervolgens wordt record voor record een record gelezen uit de live tabel, dat record geschreven naar de historische file, en pas daarna wordt het record uit de live tabel verwijderd. Als de opschoonfunktie klaar is, hebben we bijv. 400 MB aan data uit een tabel verwijderd.
Nb: Die vrijgemaakte ruimte komt pas echt vrij nadat de tabel gereorganiseerd is (de PACK verwijdert de als verwijdert gemarkeerde records).
In ADS komt alles weer samen...
Eenmaal overgestapt op een Advantage Database Server is de 2 GB limiet niet meer aan de orde; een ADS tabel kan vele malen groter zijn.
Bij de migratie van de native Foxpro Database naar een Advantage Database zal de DBF tabel (VFP) moeten worden omgezet naar een ADT tabel (ADS). Tijdens deze upload worden ook de records die eerder historisch waren gemaakt weer toegevoegd aan deze Advantage Database. Zouden we ieder jaar 1 GB aan data uit LOVR hebben opgeschoond en daarna de overstap maken naar ADS, dan hebben we in ADS ineens een LOVR tabel van bijv. 8 GB groot en hebben we weer een consistente database waarin alle data weer beschikbaar is.
Opschonen in ADS
Bovenstaande is allemaal inleiding voor waar dit topic om draait.
Technisch gezien heeft in ADS een tabel een maximale grootte die wij in Profit niet zullen halen. Wat dat betreft zullen de opschoonakties zoals we dit bij onze VFP database moesten uitvoeren om een tabel niet boven de 2 GB uit te laten komen in ADS niet aan de orde zijn. Tóch is met ingang van eind 2017 het mogelijk gemaakt om óók in ADS data op te kunnen schonen...
Als we in VFP een tabel LOVR van ongeveer 1,8 GB gingen reorganiseren kon dit wel een paar kwartier duren. In ADS hebben we voorbeelden waarin een tabel LOVR van 8 GB (exclusief de SQL indexen) in ongeveer 5 minuten werd gereorganiseerd. Vanzelfsprekend geldt dat voor ADS de response sterk afhangt van uw hardware. CPU kracht, geheugen, harddisks en netwerk zijn bepalend voor de uiteindelijke performance; dezelfde reorganisatieopdracht kostte op een andere server bijna de dubbele hoeveelheid tijd. Ach... nog steeds 10 minuten voor een tabel van 8 GB, en daarmee vele malen sneller dan we in VFP gewend waren.
Inmiddels zijn er installaties waarbij de LOVR tabel al groter is dan 50 GB. Het reorganiseren van een tabel van die omvang neemt dan vanzelfsprekend meer tijd in beslag. En, zo'n tabel is niet de enige, er zullen er meerdere zijn. Op zich nog steeds geen probleem voor de dagelijkse werking met Profit, maar... er ontstaat ineens een ander probleem. Een dergelijke hoeveelheid data gaat al snel gepaard met een bedrijf die 7x24 uur operationeel is, en waarbij we ons amper downtijd kunnen veroorloven voor een upgrade. Maar, ook bij een eventuele calamiteit waarbij indexen beschadigd zijn en er op nieuw gereorganiseerd moet worden, zal het reorganiseren van de totale database langer duren dan we ons kunnen veroorloven. Op deze wijze ontstaat er alsnog ook in ADS de wens om tabellen te kunnen opschonen v.w.b. oude data die niet dagelijks gebruikt wordt.
Sinds eind 2017 zijn de belangrijkste van de eerder genoemde opschoonfunkties (zie menu LOSYOS) ook in ADS uitvoerbaar.
Opschoonbare tabellen in ADSVerkooporders: LOVO, LOVR
Leveringen: LOLL, LOLR, LOCL
Voorraadmutaties: LOVM
Fakturatie: LOFR
EDI-/DXL: LOEO, LODU
Financieel: ADBO, ADOB, ADBB
De werkwijze hierbij is zo goed als hetzelfde als het opschonen van de VFP tabellen, echter, al deze ADS opschoonfunkties zijn zodanig opgezet dat ze kunnen opschonen terwijl andere gebruikers aktief blijven in Profit. Vanzelfsprekend zal een tabel sneller opgeschoond kunnen worden als ze voor 'alleengebruik' werd geopend, maar met als uitgangspunt dat we ons geen downloadtijd kunnen veroorloven, kunnen we in Profit door blijven werken tijdens het 'historisch maken' van deze tabellen. Als we na het opschonen de tabel kleiner willen maken, zullen we alsnog moeten reorganiseren, en daarvoor moet wél iedereen die tabel hebben vrijgegeven.
Directory StruktuurDe directory struktuur voor een ADS omgeving ziet er normaliter iets uit als:
\\\ADS_DATA_SHARE\\Het Server-adres kan bijv. een naam zijn (\\ADS-Server01) of een IP Adres (\\192.168.100.195).
ADS_DATA_SHARE is daarna standaard, en betreft de gesharede map voor meerdere datasets.
betreft een naam die is toegekend aan de gehele data omgeving van Profit. Deze bevat Test- en Produktiebestanden.
Normaliter heeft iedere installatie er hier maar 1 van, maar, technisch ondersteunen we de registratie van meerdere datasets. Verderop zal blijken dat we een 2e nodig hebben!
Deze dataset heeft normaal gesproken een naam als 'LIVE0001' of 'DATA0001'.
Een konkreet voorbeeld een dataset lokatie is dan bijv. \\ADS01\ADS_DATA_SHARE\LIVE0001.
In die directory vinden we een ADS Data Dictionary voor de Testbestanden (HP_TEST.ADD) en een Data Dictionary voor de Produktiebestanden (HP_PROD.ADD).
Daarnaast bevat deze directory de Sub-directory'svoor de tabellen van de systeemdelen:
LO - Logistiek
AD - Administratie
PK - Profit-Kontakt/Profit-Mail
NT - Incasso
SY - Systeem
en die directory's zijn weer opgesplitst in:
xxTF - Tabellen voor de Testbestanden (Test-Files)
xxTI - Indexen voor de Testbestanden (Test-Index)
xxPF - Tabellen voor de Produktiebestanden (Production-Files)
xxPI - Indexen voor de Produktiebestanden (Production-Index)
Nb: Naast deze files bevat de directory nog meer, maar dat is voor dit verhaal niet interessant.
Als we in ADS data gaan opschonen, wordt er aan de xxTF\xxPF directory een Subdirectory "HISTORY" gekoppeld.
Daarin komt per datum waarop wordt opgeschoond, een (ADT) tabel te staan met als filename de naam van de opgeschoonde tabel (bijv. LOVR) gevold door de datum.
Exporteren ADS Dataset inklusief data & history naar nieuwe Dataset
Toen we in VFP data gingen opschonen, was de overgang naar ADS de plek waar deze data weer bij elkaar kwam als een geheel. Nu zijn we echter in ADS data aan het opschonen en ook nu zullen we willen dat dit ergens samenkomt tot één nieuwe dataset die alsnog alle data bevat (inklusief de tabellen waaruit we data hebben opgeschoond). Hiertoe is nu een nieuwe tool ontwikkeld: Exporteren ADS Dataset inklusief data & history. Deze funktie is te vinden vanuit Hoofdmenu, 9,5,8,1,8.
Het enige wat we hier hoeven (of kunnen) invullen is de lokale van de nieuwe Dataset. De naam van die Dataset is al bepaald door Profit, en heeft als Identifikatie dezelfde lokatie van de huidige Dataset, echter waarbij de Dataset-naam is gewijzigd in BACKUP_DD_0001. Als die naam goed is, volstaat F1.
Nb: Mocht die Dataset al bestaan, dan wordt het laatste volgnummer opgehoogd, en krijgen we BACKUP_DD_0002 etc. Of wel een 2e en 3e Backup-dataset genereren hangt van uw wensen af danwel de diskruimte op uw server. Bedenk dat als uw live dataset 100 GB aan data bevat (inklusief tabellen, indexen, historische files) we een nieuwe set genereren van 100 GB. Doen we dat nog een keer, dan verbruiken we weer 100 GB aan data. Toch kan e.e.a. wenselijk zijn, bijv. omdat we eerst een nieuwe volledige dataset gegenereerd willen hebben (2018), voordat we vinden dat we de vorige (gemaakt in 2017) niet meer nodig hebben.
F1 zal er nu voor zorgen dat we vanuit de aktieve Dataset (\\192.168.100.195\ADS_DATA_SHARE\DATA0001) een nieuwe Dataset gaan opbouwen (\\192.168.100.195\ADS_DATA_SHARE\BACKUP_DD_0001) waarin alle data uit de "DATA0001" tezamen met de data uit de HISTORY directory's worden samengevoegd tot één nieuwe consistente Dataset. Dus, eerst hadden we bijv. een LOVR van 50 GB, toen we die gingen opschonen hebben we 45 GB overgeheveld naar HISTORY en is 5 GB overgebleven als 'live' data, en met deze funktionaliteit genereren we een nieuwe dataset waarin v.w.b. de tabel LOVR de 45 GB weer wordt samengevoegd met de 5 GB tot de oorspronkelijke tabel van 50 GB.
Het is geenszins de bedoeling dat we daarna gaan werken in deze nieuwe BACKUP_DD_0001 Dataset, immers, de DATA0001 is en blijft onze 'live' database. Als een gebruiker een nieuwe order toevoegt, zal deze in DATA0001 moeten worden opgenomen, en niet in de BACKUP_DD_0001. De data in de nieuw te genereren Dataset is wat dat betreft puur redundant en kan op ieder gewenst moment opnieuw worden gegenereerd vanuit de live database.
Het genereren van de nieuwe Dataset zorgt ervoor dat:
* er een nieuwe Dataset wordt gegenereerd, met daarin een HP_TEST.ADD en HP_PROD.ADD (de Data Dictionary's voor test en produktie) alsmede de daarvoor benodigde Directory Struktuur.
* alle tabellen die benodigd zijn om Profit op te kunnen starten worden naar zowel de Test- als de Produktie Data Dictionary van deze Dataset gekopieerd.
* voor de aktieve bestandenset geldt dat alle ADT tabellen worden gekopieerd naar de nieuwe Dataset; voor 'de andere bestandenset' geldt dat er lege structures worden opgenomen.
In praktijk zal het erop neer komen dat als we vanuit de Produktiebestanden van onze live database een nieuwe Dataset genereren, de nieuwe Dataset 'gevulde' Produktiebestanden heeft, maar óók Testbestanden heeft. We gaan dus niet én Produktie én Test kopiëren, we kopiëren alleen Produktie (als we dit vanuit de Produktiebestanden opstarten) maar zorgen er voor 'de andere bestandenset' (de Testbestanden) voor dat deze over voldoende data beschikt om ook in de nieuwe Dataset te kunnen omschakelen tussen Produktie- en Testbestanden.
Tijdens het opbouwen van de nieuwe Dataset wordt in een Listbox control bijgehouden waar Profit op dat moment mee bezig is; deze bevat informatie zoals onderstaand:
Het kopiëren van de database gebeurt in de volgorde LO, AD, PK, NT, SY. Per tabel wordt aangegeven om de hoeveelste tabel van het totaal aantal tabellen (van die Subapplikatie) het gaat. Zo betekent onderstaande 57/495 dat de tabel LOCF de 57e logistieke tabel is van in totaal 495 te kopiëren logistieke tabellen.
Tevens herkennen we in bovenstaand scherm dat de struktuur van tabel LOCF wordt gekopieerd naar zowel de Produktiebestanden alsmede de Testbestanden, maar dat alleen de data wordt gekopieerd naar de Produktiebestanden van de nieuwe Dataset. Zouden we als voorbeeld tabel LOBE nemen (bedrijven) dan zien we dat die data ook naar de Testbestanden wordt gekopieerd, immers, LOBE (bedrijven) hebben we nodig om Profit op te kunnen starten.
Als er ergens in het hele proces iets fout loopt, worden alle regels van de Listbox control rood gekleurd. In die situatie zullen we in de logfile moeten kijken wat er fout is gegaan, dat probleem moeten oplossen, en daarna zullen we opnieuw een export naar een nieuwe Dataset moeten opstarten (de oude BACKUP_DD_0001 kunnen we dan eerst verwijderen, immers, die is foutgelopen, en hebben we niets aan).
Als alle tabellen gekopieerd zijn, zal als laatste onderdeel een reorganisatie worden opgestart van de tabellen in de nieuwe Dataset.
Zowel de tabellen in Produktie- alsmede in Test zullen van indexen voorzien moeten worden; de tabellen in Test zullen op een paar na geen data bevatten en reorganiseren daardoor zeer snel. Alle indexen worden in de logfile expliciet benoemd. Dit levert een aanzienlijk aantal log registraties op, want voor alle kleine tabellen vast niet echt zinvol is, maar, met name voor de grotere tabellen is het toch een indikatie voor hoeveel tijd nodig is om de overige indexen op te bouwen.
Nb: Alle informatie die in de Listbox control wordt getoond, wordt óók in QCALLS tabel van de Data Dictionary's die gegenereerd worden opgenomen. Op die manier kunnen we (achteraf) altijd acherhalen welke opdrachten er zijn uitgevoerd, hoe lang ze hebben geduurd, en of ze succesvol zijn uitgevoerd of niet.
Als Profit klaar is met het genereren van de nieuwe Dataset, eindigt de Listbox control met het disconnecten van de 2 Data Dictionary's, en toont ze 'Finished'.
Als de tekst in de Listbox control niet rood gekleurd is, maar gewoon zwart is, zoals in onderstaand scherm, dan zijn we klaar.
Aktiveren van de nieuwe Dataset
Middels de Configuratie File van Heart kunnen we met een Tag ADSDDPATH= aangeven met welke Dataset Profit moet opstarten.
Binnen Profit hebben we twee van deze configuratie files:
NCONFIG.HRT = Netwerk Configuratie File.
CONFIG.HRT = Configuratie File Werkstation
De ADSDDPATH tag kunnen we in beide Configuratie Files opnemen, maar... let op... het is niet de bedoeling dat we dat (voor iedereen) doen.
Als wij 100 Gebruikers hebben die met Profit werken, dan willen we (natuurlijk) dat deze allemaal met dezelfde Dataset werken. Als die allemaal hun eigen Dataset zouden gebruiken dat zou de een niet zien dat de ander een order heeft toegevoegd; we zouden 100 order tabellen, 100 Voorraaditem tabellen hebben. Slaat nergens op, is niet wenselijk. Dus... het hele bedrijf werkt met één en dezelfde Dataset, bijvoorbeeld de \\192.168.100.195\ADS_DATA_SHARE\DATA0001. Omdat deze geldend is voor alle Gebruikers vinden we deze definitie in de Netwerk-Config.HRT.
Via de CONFIG.HRT kunnen we dit nu voor een specifiek werkstation overrulen. We hebben hierboven een nieuwe Dataset \\192.168.100.195\ADS_DATA_SHARE\BACKUP_DD_0001 gegenereerd. Als we nu in de CONFIG.HRT de regel ADSDDPATH=\\192.168.100.195\ADS_DATA_SHARE\BACKUP_DD_0001 en vervolgens Profit opnieuw opstarten, dan zal dit werkstation Profit opstarten met de nieuw gegenereerde Dataset.
Let op:
Het is van groot belang dat de Systeembeheerder dit voor u regelt, en dit goed inricht! Realiseer u dat als u dit verkeerd inricht terwijl u op een Terminal Server werkt, u ervoor zorgt dat alle Terminal Server Gebruikers met de backup-dataset zullen werken en de live-database niet meer gevuld wordt!
De veiligste plek om de CONFIG.HRT of de NCONFIG.HRT aan te passen, is door dit te doen vanuit Hoofdmenu,9,3,1,3 (Parameters Werkstation). Ten eerste maakt dit scherm inzichtelijk waar de ADS Data nu vandaan wordt gehaald, ze toont ook waar de CONFIG.HRT wordt opgeslagen. Dit zou dus een lokatie moeten zijn die niet ook door andere Gebruikers gebruikt kan worden.
ten tweede bevat deze Funktietoetsen om de Configuratie Files te wijzigen.
F5 = Editten CONFIG.HRT
F6 = Editten NCONFIG.HRT
Nb: Als deze toetsen niet beschikbaar zijn, dan is de ingelogde Gebruiker niet als 'Manager' gedefinieerd.
Met F5 wijzigen we de CONFIG.HRT (voor het werkstation) en voegen de regel ADSDDPATH regel toe:
Als we nu de CONFIG.HRT opslaan, en Profit opnieuw opstarten, zal Profit opstarten met de nieuwe Dataset.
Dit kunnen we kontroleren als we nogmaals naar het Hoofdmenu-9-3-1-3 scherm zouden gaan.
Willen we weer terug naar de normale Dataset (waar ook de andere Gebruikers mee werken), dan kunnen we de CONFIG.HRT nogmaals wijzigen, en hoeven we enkel een sterretje te plaatsen voor de ADSDDPATH regel. De regel zal dan niet meer worden gelezen, en de ADSDDPATH Tag uit de NCONFIG.HRT zal worden gebruikt.
Disclaimer
Merk op dat we hier een kopie maken van alle data, maar, dat we dit gewoon kunnen doen terwijl andere gebruikers aan het werk zijn. Hoewel dit zo is ontwikkeld opdat we Profit niet hoeven stil te leggen, is dit natuurlijk een manier die inconsistentie in de hand werkt. Als we een orderheader tabel kopiëren om 12:00 en de orderregeltabel is pas om 13:00 aan de beurt, dan kan die laatste tabel regels bevatten voor orders die om 12:00 nog niet bestonden en niet gekopiëerd zijn. We genereren de nieuwe Dataset dan ook niet zo zeer om de laatst toegevoegde orders en mutaties te kunnen zien, maar eerder om rapportages te kunnen maken over perioden waarvan we de data hadden opgeschoond.
Wat dat betreft mag de funktionaliteit ook worden beschouwd als een eerste 'praatplaat' voor een oplossing van het 'opschonen data' probleem. Hierbij zijn op zich al ideeën voor uitbreidingen, maar of die ook echt nodig zijn is de vraag.
Wel een consistente set
We zouden kunnen denken aan een oplossing die als meer trapsraket wordt uitgevoerd: eerst maken we de hele dataset aan en nemen we lege structures op van alle tabellen en kopiëren we alle historisch gemaakte data (de 45 GB die we uit LOVR hadden gehaald) en daarna, in een 2e etappe voegen we alleen de live data toe (tijdens die stap moet dan iedereen uit Profit zijn om te kunnen garanderen dat we een consistente set LOVO/LOVR kopiëren). In een 3e stap zouden we vervolgens de data uit de nieuwe Dataset kunnen reorganiseren. Dat gebeurt in de nieuwe Dataset, en weerhoudt de overige Gebruikers er niet van om in de live-database verder te werken.
Replicatie
Binnen ADS hebben we al een mogelijkheid om data te repliceren naar een SQL Server. "Replicatie" bestaat uit een initiële upload van de tabellen en daarna uit het stuk voor stuk verwerken van alle wijzigingen op die tabel. Wat nu hier met deze tool gemaakt hebben, komt overeen met die initiële upload die bij een Replicatie aan de orde zou zijn; immers, we moeten in staat zijn om een tabel helemaal opnieuw te uploaden naar een SQL Server en precies hetzelfde doen we nu hier, maar dan naar een andere ADS Data Dictionary. Als dat eenmaal gebeurd is, zouden we iets kunnen ontwikkelen waarmee de Replicatie haar mutaties niet repliceert naar een SQL Server, maar naar de door ons gegenereerde Dataset. Voegt een gebruiker dan een order toe in de live database, dan wordt deze automatisch gerepliceerd naar de dataset die alle data inklusief de historische data bevat.
