|
Title: Date Last Modified velden in ADS Tabellen Post by: Wouter Rijnbende on July 27, 2018, 10:39:56 am Met ingang van heden is het mogelijk om (bij gebruik van de ADS versie van Heart-Profit) de ADS tabellen te voorzien van een aantal 'Last Modified' velden.
Nb: Hoewel de funktionaliteit nog in ontwikkeling is, en nog getest moet worden, is het al wel mogelijk om hier zelf al mee te testen. E.e.a. werkt aldus vooralsnog alleen in de Testbestanden. 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? Op dit moment in niet één tabel, althans, niet automatisch! Het is het idee dat deze velden standaard in iedere tabel komen te staan. Enige probleem is dat het aanbrengen van deze velden in alle tabellen tijd kost; hoeveel tijd, dat hangt af van de grootte van uw ADS Database. Maar, met dat er installaties zijn waarbij de grootte van de ADS Database al in een krappe verhouding staat tot de maximaal gewenste downtijd voor een Upgrade, gaan we dit vooralsnog niet automatisch aan alle tabellen toevoegen. Als er een (nieuwe) tabel voor het eerst naar ADS wordt geupload of als een bestaande tabel toch al kwa Structure wordt gewijzigd, dan zouden we deze velden al wel automatisch kunnen opnemen (want kost dan geen extra tijd). Tòch doen we dit vooralsnog even niet, in afwachting van het testen van deze aanpassingen. Hoe kunnen we er dan nu toch mee aan de slag? Nadat er een Upgrade heeft plaatsgevonden (vanaf 27 juli 2018) biedt de funktionaliteit 'Database Upgrade ADS Tabellen' (Hmenu-9-9-8-3-2) een rubriek '_ADS Velden opnemen in database J/N'. (http://www.heartprofit.com/www/transfer/graphics/rnotes/2018/sypgugdb180727a.png) Als deze rubriek met 'Ja' wordt beantwoord, zullen de _ADS velden worden toegevoegd aan alle tabellen die aan de opgegeven scope (Applikatiekode en Wildcard) voldoen. Let op : Ook al suggereert dit scherm dat genoemde rubriek kan worden aangevinkt tijdens een database upgrade - dit is NIET het geval. Dus, alleen indien deze funktie via 9-9-8-3 expliciet wordt opgestart, kan de rubriek worden aangevinkt. Let op 2 : Waar het scherm een "database upgrade" suggereert, doet het qua database upgrade niets t.o.v. de laatste upgrade die al is uitgevoerd, maar kan dus wel de "Date Last Modified" velden aanbrengen. Vooralsnog kan dit alleen worden gedaan voor de Testbestanden. Nadat e.e.a. in voldoende mate is getest bij ook meerdere klanten die de ADS database gebruiken, zal e.e.a. tevens in de Produktiebestanden worden toegestaan. Let op: Als we hier enkel een vinkje plaatsen en direkt op F1 drukken zonder de scope te hebben aangepast, zullen de _ADS velden aan alle tabellen van onze ADS Database worden toegevoegd. Dit kan (zeer) lang duren. Tevens geldt dat mócht blijken dat e.e.a. alsnog niet goed werkt het zeer veel moeite kost om deze aktie ongedaan te maken! Het advies is dan ook eerst met een beperkt aantal tabellen aan de slag te gaan, alvorens de _ADS velden aan alle tabellen toe te brengen. Voorbeeld: Als voorbeeld nemen we het Artikelbestand (LOAR). De laatste velden in deze tabel zijn (bij een Upgrade van 27 juli 2018): (http://www.heartprofit.com/www/transfer/graphics/rnotes/2018/loar180727a.png) Via de Database Upgrade ADS Tabellen zetten we de filters op Applikatie LO, en Wildcard LOAR.STR en plaatsen het vinkje bij "_ADS velden opnemen in database J/N". (http://www.heartprofit.com/www/transfer/graphics/rnotes/2018/sypgugdb180727b.png) De structure van LOAR wordt (na F1) aangepast, en als we nogmaals de velden van de tabel LOAR in onze ADS Data Dictionary zouden bekijken, zien we dat de _ADS velden zijn toegevoegd: (http://www.heartprofit.com/www/transfer/graphics/rnotes/2018/loar180727b.png) N.b.: Deze eerste versie biedt een (te) simpele wijze van selektie van de tabellen die zullen worden aangepast (het is feitelijk of alles, of LOD* om alles wat met LOAD begint, te behandelen). Ook is er geen inzicht in welke tabellen eerder al gedaan zijn. E.e.a. dus om ervoor te zorgen dat het aanbrengen van de velden qua "upgrade tijd" behapbaar blijft. Title: Re: Date Last Modified velden in ADS Tabellen Post by: Wouter Rijnbende on August 13, 2018, 04:13:56 pm Een van de dingen die tijdens wat testwerkzaamheden naar boven zijn gekomen, is dat de opname van de zgn. _ADS velden tot problemen leidt bij de Replicatie naar een SQL Server. Zo zijn de velden immers wél toegevoegd aan de ADS Database, maar daarmee zitten de velden nog niet vanzelf in een eventueel aanwezige SQL Database. Alhier resteren twee opties:
a. ervoor zorgen dat de _ADS Velden ook in de SQL Database terecht komen (vervolmaken van deze funktionaliteit) b. ervoor zorgen dat het niet fout loopt. De 2e optie is degene die het minste tijd vergt, en, aangezien er op dit moment slechts één klant is die én over ADS beschikt (wat op zich al een via SQL benaderbare database betreft) én daarnaast ook nog repliceert naar een SQL Server, en die klant de _ADS velden niet in de SQL Database hoeft te hebben, is voorlopig voor optie 2 gekozen. De _ADS velden zijn daarmee (zoals de naam al impliceert) velden die enkel in de ADS Database zijn opgenomen en niet naar de SQL Database worden gerepliceerd. Wel is de replicatie / transaktiemechanisme erop aangepast dat de opname van _ADS velden niet foutloopt als er wordt gerepliceerd. |