Applicatie lagen corrupt

Ax maakt gebruik van een mooi lagen-systeem, waarbij de basis applicatie in de SYS laag zit, oplossing van partners in onder andere de BUS, de VAR voor de value-added-reseller, CUS voor klant specifiek en USR voor de gebruikers. Om maar een paar te noemen, want met Ax 2012 komen er nog een paar bij. Nu is het normaal zo dat een ontwikkelaar in een bepaalde laag AX opstart en code daarin alleen maar in die laag komt. Maar soms doet Ax rare dingen. Zo liep ik tegen het probleem aan dat ik een methode niet kon verwijderen die ik net had aangemaakt. Ax beweerde dat deze in een andere laag zat. Als ik inlogde in die laag, dan was die methode er niet. Samengevat had ik het terug kunnen brengen tot dit:

Ik log in in de CUS laag:


Nieuw form, override de run:


Zoals je ziet aan de AddressCountryRegion, worden alle lagen getoond van een element. Form1 bestaat enkel in de CUS laag. Ik verwijder de RUN:

 De run zit in de VAR? Samengevat; ik krijg deze run er niet meer uit.

Diverse zaken geprobeerd. UAC file verwijderen, AOI file verwijderen, AOS herstart uiteraard andere terminal server, zelfs de nieuwste kernel van Ax 2009. 

Uiteindelijk heb ik de applicatie opnieuw opgebouwd. Dit deed ik in de volgende stappen in een TEST ogmeving:

1. Bepaal de lagen waarin code zit. In dit geval: CUS, VAP, VAR, BUS en SYP/SYS.
2. Op volgorde van USR tot de SYP (SYS/SYP dit zelf niet):
      a. Maak een project met alle elementen in de laag
      b. Exporteer het project, met behoud van ID's. _alles_; dus niet alleen die laag
      c. Stop de AOS, verwijder de AOI en AOD file uit de applicatie, start de AOS

Nu had ik per laag de elementen van die laag en een Ax omgeving met enkel de SYS/SYP laag.
TIP: zet nu een breakpoint in de Application.dbSynchornize:

Bij een grote test database is het nogal een zware operatie en het is zonde als applicatie nog niet af is. Een return true; werkt ook, maar als de Application class is aangepast in de laag dan wordt deze code ongedaan gemaakt. Zet variabele 'ok' op true en sleep de executiepointer naar de volgende regel (dus de super niet uitvoeren)

Vanaf het laatste laag-project dat gemaakt is, per laag-project:
3. Importeer met behoud van ID's de elementen en verwijderen elementen. Soms zijn meerdere keren import nodig; een EDT verwijst naar een tabel en dezelfde tabel naar een EDT, krijg je bij een eerste import compilatie problemen.
4. Compileer het project en controleer op compilatie fouten.


Het kan zo zijn (in mijn geval) dat de partner code in de VAR laag had gebasseerd op code in de CUS laag. Dus bij de import in de VAR kreeg ik dus fouten en moest elementen uit de CUS in de VAR laag overzetten. Bij database tabellen/velden is dit lastig vanwege databehoud, dus ik had besloten delen in de CUS laag al op te leveren voordat de VAR laag compileerde. Het was bij mij zelfs zo, dat de BUS laag enkele marco's uit de SYP laag had verwijderd die in de VAR laag weeg waren toegevoegd. Even logisch verstand gebruiken bij deze gevallen.

Bij de 2e import van de CUS laag liep ik nog tegen een melding aan:
 Bezig met importeren van class INTEditLinesView met ID 41375. ID is al geactiveerd door class INTEditLinesDialog. In de AOT is er inderdaad een INTEditLinesDialog met ID 41375, de XPO:

Vanwege onduidelijke redenen is er een verschil in de export tussen deze waarden. Na correctie met notepad in de xpo ging het wel goed.

Na de laatste laag een volledige compilatie en synchronisatie. Omdat de ID's van de dataelementen hetzelfde zijn, zou je nu een database restore kunnen doen van Live of Dev om de applicatie te testen. Er zou geen dataverlies mogen optreden, wat uiteraard onwenselijk is.

Nu was het wel mogelijk methoden weer te verwijderen.