In topic
http://ha1.heartprofit.nl/profit/index.php?topic=26058.0 wordt beschreven dat als we eenmaal (met AdsBackup.exe) een backup hebben gemaakt van onze Data Dictionary, we vanuit Profit een nieuwe ADS omgeving kunnen aanmaken, en de backup daarin kunnen restoren. Per heden is gebleken dat dit toch niet (altijd) korrekt is! Dit blijkt alles te maken te hebben met de lokatie van de indexfiles!
De tekstpassage in het genoemde topic is derhalve m.i.v. heden gedeaktiveerd.
"Nieuwe omgeving"
Eerst maar eens uitleggen wat we dáár precies mee bedoelen...
Op de ADS Server maken we altijd een Share
ADS_DATA_SHARE aan. Hierbinnen hebben we dan eerst een Subdirectory om een volledige Dataset (inklusief Test- en Produktiebestanden) van een 'omgeving' aan te kunnen geven. Deze subdirectory heet bij de klant veelal '
LIVE0001', om daarmee 'de live omgeving' mee aan te geven. De '0001' duidt dan op een volgnummer #1. Bij HEART zelf zal dit volgnummer bij iedere nieuwe Test waarvoor een nieuwe Data Dictionary wordt aangemaakt oplopen; bij de klant zelf normaliter niet, maar, zie het restore topic, dit zóu gebruikt kunnen worden om naast de bestaande LIVE0001 omgeving een tweede set aan te kunnen maken (indien dat wenselijk blijkt, immers, alle gebruikers zullen òf met de één, òf met de andere set werken, dus, in praktijk zullen we er geen twee hebben).
Nb: Bij HEART zal zo'n 'omgeving' overigens ook de naam van een installatie van een klant kunnen bevatten; denk hierbij aan \\ADS01\ADS_DATA_SHARE\Klant-X\HP_PROD.ADD versus \\ADS01\ADS_DATA_SHARE\Klant-Y\HP_PROD.ADD.
Tabellen (ADT's) relatief t.o.v. Data Dictionary
Binnen een Advantage Data Dictionary (ADD file) is de lokatie van de Tabellen (de ADT files) relatief t.o.v. de lokatie van de Data Dictionary (de ADD file).
Als we via de Advantage Data Architect in de Eigenschappen van een Tabel kijken, zien we dat het relatieve path op bijv
.\LO\LOPF\LOAR.ADT staat. Met andere woorden, als onze Data Dictionary zich bevindt op:
\\ADS01\ADS_DATA_SHARE\LIVE0001\HP_PROD.ADD dan zal deze Tabel zich bevinden op:
\\ADS01\ADS_DATA_SHARE\LIVE0001\LO\LOPF\LOAR.ADT.
Omdat de Lokatie van deze Tabellen
relatief aan de Lokatie van de Data Dictionary is, geldt dat als we een Backup maken van LIVE0001, dan een nieuwe Dataset LIVE0002 aanmaken, en onze Backup restoren in LIVE0002, de gerestorede data ook netjes in dié dataset relatief t.o.v. de Data Dictionary zal staan, nl. in
\\ADS01\ADS_DATA_SHARE\LIVE0002\LO\LOPF\LOAR.ADT.
Lokatie Indexen
Bij indexen gaat dit toch nèt even anders...
Op het moment van dit schrijven kunnen we het voorbeeld niet meer simuleren, maar er staat ons iets van bij dat de Indexlokatie óók relatief was, en iets als "
.\LO\LOPI\LOAR_IN1.ADI" bevatte. Als dat zo is, "Ja", dan zouden we gewoon de Backup van de LIVE0001 moeten kunnen restoren in een LIVE0002, en zou de indexlokatie daar opnieuw worden aangemaakt... Wat er precies gewijzigd is waardoor dit niet meer het geval is is onduidelijk; wel geldt dat het vorige topic uit 2012 dateert, en er sindsdien veel veranderd is.
Een situatie waar we nog wél een schermprint van kunnen maken, is de volgende:
Deze situatie kan ontstaan als er een index wordt aangemaakt, zonder dat daarbij een Path wordt meegegeven. De index wordt dan aangemaakt in dezelfde directory als waarin de ADT files staan. Dit is een methode die wij vanuit Profit niet gebruiken, al was het maar zo omdat we de indexen altijd in een \
LOx
I\ directory willen hebben staan, en niet in een \
LOx
F\ directory. Ook voor deze situatie zou gelden dat als de Index altijd wordt aangemaakt in dezelfde directory als waarin de ADT zich bevindt, en die directory weer relatief is t.o.v. de lokatie van de ADS Data Dictionary, een restore van LIVE0001 naar LIVE0002 ertoe zou moeten leiden dat ook deze index in LIVE0002\LO\LOPF\LOAR_IN1.ADI terecht zou moeten komen...
Als het goed is zal een Profit Data Dictionary altijd een volledig UNC Path bevatten, zoals bijv: \\HA5\ADS_DATA_SHARE\xxxxxxx\LO\LOPI\LOAR_IN1.ADI
en dát is dan meteen de situatie waarin een restore naar een andere omgeving niet werkt...
Wij kunnen vanuit Profit immers wel een nieuwe omgeving
LIVE0002 aanmaken, met daarin een nieuwe
HP_TEST.ADD en een
HP_PROD.ADD, maar, als we een Restore uitvoeren, dan restoren we een eerder gebackupte Data Dictionary (bijv HP_PROD.ADD) en deze bevat voor iedere Tabel de indexdefinities met deze fixed lokatie daarin. Met andere woorden, als de lokatie van de Indexfile niet 'relatief' was, dan zal er niets zijn op basis waarvan ADS kan verzinnen dat de index nu op een andere lokatie (in LIVE0002) moet worden aangemaakt...
Het effekt is dat de restore de tabellen wél restored in de LIVE0002 directory (immers, de lokatie van de tabellen is relatief t.o.v. de Data Dictionary), maar de indexen worden gewoon gerestored naar hun oorspronkelijke lokatie, en dat is in de LIVE0001 map. Het effekt daarvan is dat we ineens twéé datasets zullen hebben, met gescheiden databases (de een in LIVE0001, de ander in LIVE0002) maar welke beide hun indexen uit LIVE0001 lezen. Dat dit fout gaat mag duidelijk zijn; zouden we een record toevoegen, dan komt deze maar in één van beide datasets terecht en aangezien beide datasets dezelfde indexen delen, leidt dat tot een fout:
Resumerend: Met dat u als gebruiker niet op voorhand van iedere tabel weet of de betreffende indexfile een 'relatieve' of 'vaste' lokatie impliceert, is het
niet toegestaan om de restore naar een andere directory te restoren! Het lijkt er immers op dat u hiermee de indexen in de oorspronkelijke omgeving mee kunt verknallen.
Met dát dit zo werkt staat de weg alsnog weer open om formeel indexen op een separaat index-volume te plaatsen.
Zie ook topic
http://ha1.heartprofit.nl/profit/index.php?topic=29359.0
