Let op: geen restore naar andere Data Dictionary

[Wouter Rijnbende]

In een poging de produktieomgeving te backuppen en te restoren in een andere DataDictionary (test) lijkt het erop dat ik het voor elkaar heb gekregen iets te verzieken in de Data Dictionary, resulterend in de onderstaande melding. Om ellende te voorkomen: probeer dit dus niet ! De Test Data Dictionary verwijst vervolgens naar tabellen die in produktie staan, en de struktuur van deze tabellen komt niet overeen met dat wat de Data Dictionary van test aangeeft.

[Wouter Rijnbende]

Dit probleem was te herstellen door vanuit de Advantage Data Architect de betreffende tabel te verwijderen uit de Data Dictionary, vervolgens de verbinding met de Data Dictionary te verbreken en opnieuw te connecten, en daarna via Rightclick op Tables met Add Existing table te navigeren naar de ..\AD\ADPF directory en de tabel opnieuw op te nemen. Mogelijk moet de tabel daarna opnieuw gereorganiseerd worden om de auto-index opnieuw aan te maken.

[Wouter Rijnbende]

Om t.z.t. nog eens uit te zoeken, maar bij deze genoteerd voor het geval we een foutsituatie niet weten te herstellen, in de ARC subdirectory van de installatie van Advantage in ProgramFiles staat ook een commando 'freeadt'. Zie ook http://devzone.advantagedatabase.com/dz/WebHelp/Advantage11.1/index.html?ace_adsddfreetable.htm
Die konden we wel eens een keer nodig hebben.

[Wouter Rijnbende]

Mijn Test-Data Dictionary is verziekt (en verwijst naar produktiebestanden). Als ik een tabel ontkoppel uit de Data Dictionary en hem opnieuw uit de ..\xxTF directory wil opnemen, lukt dat niet omdat dit aangeeft dat mijn tabel geen free table is. Dat is waar die freeadt.exe voor bedoeld zal zijn. Met een opdrachtregel "freeadt -p<password> d:\ads\data0001\ad\adtf\*.adt" worden alle ADT's in die directory 'free' gemaakt. De verwijzing die in die tabel is opgenomen en naar de Data Dictionary linkt is wordt dan verwijderd. Resultaat is dat ik de tabel daarna wel gewoon aan de Data Dictionary kan koppelen (wat weer de link met die data dictionary bij de tabel zal doen opnemen).

Helaas ben ik nu wel mijn indexen kwijt ! maar die kunnen met reorganiseren opnieuw worden opgebouwd (met de benodigde problemen om Profit op te kunnen starten zonder indexen).

De data ben ik gelukkig niet kwijt.

Let op: dit mag uiteraard alleen i.g.v. zo'n foutsituatie worden gebruikt, want binnen Profit is het altijd de bedoeling dat de tabellen vanuit de Data Dictionary worden geopend.

[Wouter Rijnbende]

Vandaag nog weer ergens een ongewenst effekt gekonstateerd, en de enige 'oorzaak' die ik er bij kan bedenken zou deze foutgelopen restore moeten zijn.

Als we in VFP een record toevoegen aan een database, dan heeft een veld welke we niet expliciet replacen altijd een defaultwaarde. Een Characterveld bevat spaties, een Numeriek veld 0, een Logical .F. etc. In ADS (of algemeen SQL) geldt dat een veld welke niet gereplaced wordt een NULL value heeft, en, die NULL value leidt tot problemen. Op zich was dit al bekend, en om die reden zal bij het uploaden van een tabel naar ADS ieder veld een expliciete defaultvalue toegekend krijgen, opdat er geen NULL values in de database komen te staan.

Ik konstateer vandaag dat deze defaultvalues niet meer aan de tabel gekoppeld zijn ! met als gevolg dat er weer NULL values in de tabel staan. Een index, met een FOR clause op "NOT <veldwaarde>" (een FOR op een logical veld) bevat nu ineens geen records meer waarvan de veldwaarde NULL is, en de betreffende funktionaliteit dus niet meer werkt.  Ook is bekend dat NULL values problemen opleveren bij sorteringen.

[Peter Stordiau]

Heb ik het goed als ik concludeer dat het feitelijke euvel is dat de Data Dictionary dus eigenlijk is "verziekt" ?
En dat als dat is (of zou zijn) opgelost dat dit probleem er dus ook niet meer is ?

Of is het zo dat je alle records van een (alle, lijkt me) tabellen door moet met de expliciete Replace ?
Lees : Als je achteraf de defaultwaardes in de DD aanbrengt, gaat ADS dit niet uit zichzelf toepassen. (?).

Ik breng/vraag het zo, omdat je dit als een extra probleem lijkt te brengen, wat wellicht nooit een extra probleem is omdat
a. die Restore (zoals beschreven) sowieso nooit kan werken (kan je nog wel een extra probleem verzinnen, maar wat moeten we ermee)
of
b. Na weer aanbrengen in de DD van de defaultwaardes (wat dan wel moet kunnen, achteraf !) wordt alles vanzelf weer bijgewerkt (dus ook in dit geval heeft het noemen zoals gedaan weinig nut want vanaf heden is het geen probleem meer).

Lees : Je deelt wellicht iets mee wat geen merites heeft, dan wel niemand kan raden wat nu de werkelijke mededeling is.
Een fijne constatering is het natuurlijk wel ...

[Wouter Rijnbende]

De mededeling is de konstatering dat het is opgetreden, en de mogelijke oorzaak.
Of en welke problemen dit oplevert is niet op voorhand te zeggen.

In een specifiek voorbeeld (de Periode Afsluiting) zorgde dit voor problemen. De Periode Afsluiting bestaat uit 2 delen: a. het kopieren van de vorige periodetotalen naar de nieuwe periodetotalen en b. het verwerken van het saldo van de huidige periode in die periodetotalen. Die eerste stap werd daarbij niet korrekt uitgevoerd (het daarvoor bestemde tellertje op het scherm zag je niet opgehoogd worden). Dit dit geval veroorzaakt door een index met een FOR clause op een logical value (FOR .NOT. JRAFSLT), en welke niet de juiste records bevatte omdat JRAFSLT een NULL value had.

Als tijdens een Database Upgrade nieuwe velden worden toegevoegd aan een database worden de records in de bestaande database al voorzien van de juiste initiele waarde. De Database-Upgrade is nu uitgebreid met een extra kontrole om dit eufel te verhelpen mocht het aan de orde zijn. Daarmee is niet per definitie gezegd dat alle problemen ook meteen verholpen zijn. Zou je je periode direkt na afsluiten heropend hebben (omdat je ziet dat er wat mis gaat), dan worden de aangemaakte records ook niet verwijderd (immers ook de verwijder funktie kan de records niet meer vinden).

Bij de ADS klanten heb ik wat kontroles in een aantal tabellen gedaan. Overal waar ik gekeken heb was de defaultwaarde nog gewoon aanwezig. Wat dat betreft geen reden om aan te nemen dat het ergens fout is gedaan, en vandaar het vermoeden dat dit veroorzaakt is door de eerdere test restore perikelen. Wel iets om in het achterhoofd te houden als we ooit eens ergens onverklaarbare resultaten krijgen in funkties die het altijd gewoon gedaan hebben.