Date Last Modified velden in ADS Tabellen (2)

[Wouter Rijnbende]

Eind juli 2018 is in topic http://ha1.heartprofit.nl/profit/index.php?topic=28630.0 een tijdelijke manier besproken om ADS tabellen te kunnen voorzien van _ADS velden.  Er waren al wat testjes uitgevoerd met deze _ADS velden en 'inbouwen in de Database Upgrade (die al Restructure opdrachten bevat)' was de snelste manier om een klant hiermee te kunnen laten testen. Toch was die methode weinig gebruikersvriendelijk, en eigenlijk ook erg gevaarlijk als je niet wist wat je aan het doen was (zie ook hoofdstuk "Alleen Restructure _ADS velden").
Per heden derhalve een nieuwe beschrijving van dit topic:

Bij gebruik van de ADS versie van Heart-Profit is het mogelijk om de ADS tabellen te voorzien van een aantal 'Last Modified' velden.

De extra aan de ADS Database toegevoegde velden krijgen allen een veldnaam beginnend met _ADS. Deze _ADS velden staan altijd onder (als laatste velden) in de tabel; dwingt een nieuwe Update af dat er normale Profit-velden bij komen in de Database, dan zullen deze bóven de _ADS velden in de structure worden toegevoegd.


Welke _ADS Velden zijn er?De volgende _ADS velden worden op dit moment onderkend (en toegevoegd aan de ADS Tabellen):

_ADSTimeCreated
Een veld waarin de datum en tijd wordt geregistreerd van het moment van aanmaken van het record.
Datum-/tijd worden opgenomen in het formaat eejjmmdduummsshh (2018072513160232).

_ADSTimeModified
Een veld waarin de datum en tijd wordt geregistreerd van het moment van beschrijven van het record. Merk op dat een record ook direkt (of kort) na het Toevoegen wordt beschreven. Deze situatie wordt niet apart afgehandeld t.o.v. een wijziging van een bestaand record; aanname mag zijn dat als de _ADSTimeModified binnen een fractie van een seconde na de _ADSTimeCreated ligt, we ervanuit mogen gaan dat het record niet is gewijzigd nadat ze is toegevoegd.
Datum-/tijd worden opgenomen in het formaat eejjmmdduummsshh (2018072513160232).

Nb: Omdat het in de lijn der verwachting mag liggen dat de _ADSTimeModified gebruikt gaat worden om 'iets' te gaan doen met records die na een bepaald moment zijn gewijzigd, wordt de tabel tevens uitgebreid met een SQL Index op dit veld. Op die manier kunnen we Queries met een filter op Datum-/tijd laatste wijziging zeer snel worden uitgevoerd.

_ADSUserModified
Bevat het Userid van de in Profit ingelogde Gebruiker op het moment dat het record werd beschreven.
Bevat daarmee de Identifikatie van de Gebruiker die het record voor het laatst gewijzigd heeft (en wel op het tijdstip zoals aangegeven in _ADSTimeModified) en met als opmerking dat als het record zojuist is toegevoegd, dit dus het Userid is welke het record heeft toegevoegd.
Het Userid die het record aanmaakte wordt niet expliciet bewaard. Technisch is dat best mogelijk, maar, voor nu is het niet 'gevraagd'.

_ADSOriginalSuper
In praktisch iedere tabel komt wel een veld LOSU_SID, XXSU_SID of LOBE_BID voor die representatief is voor het aktieve bedrijf (intern ook wel "de SUPER" genoemd). Als we een record in Profit verwijderen, dan wordt dit Super-veld overschreven met een deleted mark. Hoewel we de 'als verwijderd gemarkeerde' records in de database kunnen herkennen, is door het aanbrengen van het deleted mark gaat wel de informatie 'uit welk bedrijf kwam dit record oorspronkelijk' verloren. Het veld _ADSOriginalSuper wordt bij het 'verwijderen' gevuld met de Bedrijfs-Identifikatie van het oorspronkelijke Super-veld.


Waar wordt de inhoud van deze velden weergegeven?Vooralsnog helemaal nergens. De velden worden enkel toegevoegd aan de database en vanuit Profit gevuld.
Mogelijk (nog niet expliciet getest) komen de velden al wel automatisch naar boven in het SideGrid van deze tabel, maar, vooralsnog zijn de velden alleen opvraagbaar vanuit de Advantage Data Architect. De velden zijn dan ook bedoeld voor eigen queries en het aldus kunnen achterhalen van de laatste wijzigingen (en door wie, indien gewenst).


In welke ADS Tabellen worden deze velden opgenomen?In Menu "Systeembeheer - ADS Funkties" (Hoofdmenu,9,5,8,1) leidt menu optie #5 tot onderstaande Listmover control, waarmee u zelf kunt bepalen aan welke tabel(len) u de _ADS velden wilt toevoegen:

Boven in het scherm vinden we als eerste een Combobox met daarin een keuze voor een van de volgende Applikatie Kodes:

LO = Logistiek
AD = Financieel
PK = Profit-Kontakt
NT = Incasso
SY = Systeembeheer

Met de waarde uit deze Combobox wordt een eerste filter gelegd over de tabellen die in de Listmover control zullen worden getoond; kiezen we voor Logistiek, dan zullen we niet worden vermoeid met bijv. de Financiële- of Systeem tabellen.

Vervolgens bestaat de Listmover uit twee Lists.

Links treffen we alle tabellen aan waarbij de _ADS velden NIET zijn (of moeten worden) opgenomen.
Rechts treffen we de tabellen aan waarbij de _ADS velden al WEL zijn (of moeten worden) opgenomen.

De Lists zijn opgebouwd uit een aantal kolommen:

Tabel	- Naam van de betreffende Tabel
Omschrijving	- Omschrijving van de Tabel, zoals opgenomen in Documentatie Cross Reference
MB	- De grootte van de tabel, uitgedrukt in een aantal MB.
Status	- Een kolom waarin Profit wat aanvullende data toont.

Willen we de _ADS velden opnemen in een bepaalde tabel, dan moeten we de Tabel van links- naar rechts verplaatsen. Zijn er _ADS velden opgenomen in een tabel en willen we dat niet meer (desnoods omdat er ergens een proces foutloopt), dan verplaatsen we de Tabel juist van de rechter- naar de linker List.

Een voorbeeld:

We willen de _ADS velden opnemen in de Tabel Artikelen (LOAR). De _ADS velden zijn nog niet opgenomen, dus, de (Logistieke) Tabel LOAR zullen we moeten zoeken in de List aan de linkerzijde. We kunnen die tabel nu naar de rechter List verplaatsen, door de Tabel in de linker lijst te selekteren en vervolgens op de button met het enkele pijltje naar rechts (zie hieronder) te clicken. Het is ook mogelijk om te dubbelclicken op de betreffende tabel LOAR, dan wordt ze ook verplaatst naar de andere List.

De buttons met een enkel pijltje verplaatsen de geselekteerde Tabellen van de ene naar de andere kant, de buttons met de dubbele pijltjes (zie hieronder) verplaatsen alle items uit de List van de ene naar de andere kant.

De Tabel LOAR verschuift nu van de linker- naar de rechter List, en krijgt daar de status 'Pending' toegekend:

'Pending' betekent hier dat de Tabel weliswaar in de List '_ADS Velden wel opgenomen' staat, maar dat de daadwerkelijke (het restructuren van de Tabel) nog niet heeft plaatsgevonden; dát gebeurt pas nadat er met F1 wordt verwerkt. Op deze manier kunnen we eerst meerdere Tabellen selekteren en van links- naar rechts verplaatsen (of andersom), en al deze opdrachten in 1x verwerken met F1.
De status 'Pending' wordt toegekend zodra een Tabel wordt verplaatst naar "de andere" List. Deze status is tevens de trigger voor de F1 om te bepalen welke tabellen 'verwerkt' moeten worden. Merk op dat als een Tabel LOAR van links- naar rechts wordt verplaatst, en ze daarna weer terug verplaatst wordt naar links (per saldo is er dan niets veranderd) ze tóch de status 'Pending' krijgt. Tijdens de F1 verwerking zal ze dan wél behandeld worden, maar zal alsnog gekonstateerd worden dat de tabel niet gewijzigd hoeft te worden.

Verwerken - Opnemen _ADS Velden"
Bij het verwerken (F1) worden eerst alle tabellen uit de rechter List verwerkt (Op te nemen). Aangezien de List veel meer Tabellen kan bevatten dan er op het scherm zichtbaar zijn, zal tijdens de verwerking de List automatisch 'scrollen' naar het Listitem welke verwerkt wordt; zie is (dus) altijd zichtbaar. Bij het opnemen worden de 4 genoemde _ADS Velden opgenomen in de betreffende Tabel(len). Tevens wordt er een SQL Index aangebracht op het Veld _ADSTimeModified; dit, omdat we er vanuit mogen gaan dat de opname van dit veld in de Tabel mag uitlokken dat we Query's gaan uitvoeren in de vorm van "laat maar zien wat er sinds gisteren gewijzigd is".

Tijdens de verwerking wordt in kolom Status aangegeven waar het systeem op dat moment mee bezig is:
- Structure aanpassen
- Index op _ADSTimeModified
- Verwerkt

Als er een fout optreedt, wordt de verwerking van de betreffende Tabel afgebroken en gaat ze verder met de volgende Tabel. Kolom Status wordt dan gevuld met:
- Geallokkeerd (treedt op indien een andere Gebruiker (of proces) de betreffende Tabel in gebruik heeft)
- Fout: <errorcode>


Verwerken - Verwijderen _ADS Velden"
Nadat de rechter List is verwerkt, worden de tabellen uit de linker List verwerkt. Iedere Tabel die daar de status 'Pending' heeft (en dus een keer verplaatst is uit de rechter List) wordt verwerkt, nu in omgekeerde volgorde.

- Verwijderen Index Sxx (verwijdert een eventueel bestaande SQL index op het _ADSTimeModified veld)
- Structure aanpassen
- Verwerkt

met dezelfde foutmeldingen als in het vorige stuk beschreven.

Omdat de verwerking enige tijd in beslag kan nemen, zal er zodra de verwerking klaar is expliciet een melding volgen (de kans is immers groot dat we een tekst 'Verwerkt' die een seconde in de Statusbar wordt getoond over het hoofd zullen zien).

Als we nu in de Advantage Data Architect de tabel LOAR zouden bekijken, dan zien we dat er 4 _ADS velden zijn toegevoegd onderin de tabel:

Alleen Restructure van _ADS veldenDeze Listmover versie van de opname van _ADS velden vervangt de eerder (tijdelijk) ontwikkelde variant die even snel was ingebouwd in de Database-Upgrade. Die versie stond de Gebruiker op zich al wel toe om _ADS velden in een bepaalde tabel aan te brengen, maar 'selekties'  (anders dan LOA*) konden niet worden gemaakt. Een veel gevaarlijker probleem was dat die tool ging uitlokken dat iemand een Database Upgrade ging doen terwijl ze met gescheiden Test-/Produktiebestanden werkt én een Upgrade pending had (dit houdt in dat we in de Testbestanden een Upgrade hebben uitgevoerd welke nog niet is doorgezet naar de Produktieomgeving).
Bij de aanwezigheid van de module Profit-Base-Test mag een gebruiker eigenlijk nooit expliciet een Database Upgrade uitvoeren; de "Upgrade van Heart naar de Testomgeving" zal de bestandsstruktuur in de Testbestanden wijzigen, en de "Upgrade van Test- naar Produktie" zal de bestandsstruktuur van de Produktiebestanden aanpassen. Met het inbouwen van de _ADS veld funktionaliteit in die funktie zijn we dus tevens gaan uitlokken dat iemand (zonder formeel een Upgrade van Test- naar Produktie te hebben gedaan) de Structures van de tabellen in de Produktiebestanden gelijk maakt aan die van "de laatste upgrade", terwijl de programmatuur daar nog niet op anticipeert. Dit was dan ook een van de redenen dat we in de oude versie de _ADS velden niet konden aanbrengen in de Produktiebestanden.

De nieuwe versie handelt enkel en alleen het opnemen danwel verwijderen van de _ADS velden (en indexen) af en wijzigt verder niets aan de tabel struktuur. Deze versie zal ook een stuk sneller zijn dan de vorige versie, omdat bij een Database-Upgrade de Restructure altijd alle indexen van de tabel ontkoppelt en daarna alle indexen opnieuw opbouwt; deze tool doet dat expliciet niet, en beperkt zich enkel tot het opnemen of verwijderen van SQL indexen op _ADS velden (vooralsnog alleen op _ADSTimeModified).

Niemand in ProfitHet kunnen aanpassen van een bestands struktuur zal (net als bij een Upgrade) vereisen dat alle Gebruikers (en eventuele processen buiten Profit) zijn afgemeld van de ADS Data Dictionary. Profit voert e.d. kontrole niet uit door het aantal Connections te tellen wat is ingelogged op de ADS Data Dictionary, maar zal kontroleren of "alle Profit bestanden zijn vrijgegeven". Ook dit hoeft niet altijd "alles" te zeggen, immers, als alle Gebruikers op het Hoofdmenu hebben "vrijgegeven", zullen wij niet detecteren dat er nog Gebruikers opgestart zijn. Toch is de kontrole alhier niet anders dan bij het uitvoeren van een Upgrade.

Hoe dan ook, nèt als bij een Upgrade zal deze tool het opstarten van Profit blokkeren (als ze dat al niet is) en zal worden gekontroleerd of alle Profit Tabellen zijn vrijgegeven. Indien een Tabel nog elders in gebruik is, zal dit worden gemeld en wordt de verdere verwerking afgebroken. Dit gebeurt óók als het om andere Tabellen gaat dan de Tabellen die kwa _ADS velden gewijzigd worden! Het gaat er immers niet alleen om dat dié Tabellen zijn vrijgegeven, het gaat er om dat er niemand in Profit zit!

Nb: Dat laatste heeft er dan weer mee te maken dat de bestands struktuur normaliter alleen gewijzigd wordt bij een Upgrade. Per Profitsessie wordt van iedere Tabel die geraakt wordt éénmalig informatie verzameld (zoals welke Velden er in de Tabel zitten, welke lengtes, welke Indexen etc.). Het aanpassen van de Database Struktuur vereist dan ook dat alle Gebruikers expliciet Profit opnieuw moeten opstarten. Dit gebeurt als vanzelf als iedereen voordat de Database wordt aangepast uit Profit is.


SQL Database en ReplikatieDe _ADS velden worden puur en alleen in de Tabellen van de ADS Database opgenomen. Als we vanuit ADS repliceren naar een SQL Database, dan zullen deze _ADS velden niet worden opgenomen in de Structures van de SQL Tabellen, noch zullen deze waarden worden gerepliceerd naar SQL.

Met ingang van 31 juli 2019 worden deze _ADS Velden óók opgenomen in, en gerepliceerd naar de SQL Server Database. Let op: daarmee zien we dus in de SQL Server Database welke records er "in ADS" nieuw zijn t.o.v. enig moment. Los daarvan zou vergelijkbare funktionaliteit ook voor de SQL Server Database gewenst kunnen zijn.