In topic
http://ha1.heartprofit.nl/profit/index.php?topic=29131.0 is beschreven hoe we vanuit de ADS versie de data vanuit Profit kunnen repliceren naar SQL Server. Hierbij zal iedere mutatie in Profit leiden tot een zogenaamde
Transaktie, die vervolgens door een Replikatie PC wordt opgepakt en wordt gerepliceerd naar de SQL Server.
Overigens betreft dit niet puur en alleen het repliceren, immers, tijdens dit proces wordt ook bepaald (en bijgehouden) wat er allemaal in een bepaalde Transaktie werd gewijzigd. Zo leidt dit tot een database die kan aantonen wanneer een record is toegevoegd, wanneer ze is gewijzigd, en wát er is gewijzigd (hooguit ontbreken de rapportages nog die daar iets meer doen).
Het repliceren begint met een initiële upload van de ADS Tabel naar de SQL Server Database. Daarna worden alle mutaties in Profit naar die SQL Server Database gerepliceerd. Als de Replikatie PC "bij" is (lees: alle openstaande transakties heeft verwerkt) zou de tabel op de SQL Server "dezelfde data" moeten bevatten als de tabel in Profit.
Nb: "Dezelfde data", rekening houdend met het feit dat een Bedrijf in Profit wel/niet Transaktioneel gedefinieerd kan worden, dit óók voor een Tabel kan gelden, en we daarnaast nog "Upload Filters" gedefiniëerd kunnen hebben die stellen dat bijv. alleen data van de afgelopen 2 jaar geupload moeten worden.
Als de SQL Server Database op enig moment niet meer synchroon loopt met de ADS Database, kan dat worden verholpen door de betreffende ADS Tabel opnieuw naar de SQL Server Database te uploaden. Hoewel deze optie altijd werkt, kost dit "tijd". Hoeveel tijd hangt volledig af van de grootte van de tabel en het aantal indexen. Tijdens het uploaden van data naar uw SQL Server wordt in het scherm getoond met welke snelheid dit gebeurt. Stel dat hier 6 MB/sec uitkomt, dan impliceert dat dat een tabel zoals LOVS (Verschijningsvormen) die ongeveer die grootte zal hebben, in een seconde opnieuw geupload is. Gaan we echter een Tabel ADBO (Boekingen) van 20 GB opnieuw uploaden, dan hebben we daar toch wel een uurtje voor nodig. Het opbouwen van de indexen op de SQL Server zal vervolgens alsnog ruim een uur in beslag kunnen nemen.
Met ingang van heden is er een nieuwe tool ontwikkeld die de data van de in Profit (vanaf een op te geven datum) gemuteerde records opnieuw kan synchroniseren met de SQL Server Database. We vinden deze tool via Hoofdmenu-9-5-7-5:
Op basis van de in Profit bekende Transakties, zal deze tool alle gemuteerde records opnieuw bezoeken en kwa inhoud opnieuw repliceren naar de SQL Server Database. Bovenin het scherm kan middels een datumveld worden aangegeven vanaf welke datum dit dient te gebeuren; deze datum kan worden gevuld met de datum "waarop alles nog wel goed was", bijv. de datum waarop de betreffende tabel voor het laatste in zijn geheel naar de SQL Server was geupload.
Het scherm bevat verder een Listmover control. Links in deze Listmover control staan alle Transaktionele Tabellen; dat zijn de tabellen die feitelijk naar de SQL Server worden gerepliceerd. Door een tabel van links naar rechts te verplaatsen wordt ze opgenomen in de lijst van tabellen waarvan we willen dat ze 'rechtgetrokken' moeten worden. Waar we bij het Uploaden van tabellen dit "per Applikatiekode" doen, toont deze lijst de volledige set van Transaktionele Tabellen. Dit, opdat we 's avonds een run kunnen opstarten van meerdere tabellen, en niet hoeven te wachten tot een tabel klaar is om de volgende selektie te kunnen maken.
Als we onze selektie gemaakt hebben, verwerken we dit met F1. Daarna zal Profit van alle Tabellen die in de rechterlijst voorkomen op basis van de Transakties bepalen welke records er gemuteerd zijn, deze records herbezoeken, en opnieuw synchroniseren naar de SQL Server Database. Per tabel wordt middels een (aflopend) tellertje bijgehouden hoeveel records er nog verwerkt moeten worden. Als de tabel verwerkt is, toont ze hoeveel records er verwerkt zijn.
Voor welke tabellen starten we de run op?Hier is geen echte richtlijn voor, maar, tot op heden was de klant zélf goed in staat om te konstateren wanneer er iets mis was met een bepaalde SQL Server tabel; er ontbrak data in rapportages die zich baseerden op de SQL Server database, terwijl deze data wel in Profit beschikbaar was. Al dan niet met hulp van Heart kan worden bepaald welke tabellen dan opnieuw moeten worden 'rechtgetrokken'.
Wanneer starten we de run op?We hebben er voor gezorgd dat niet iedereen uit Profit hoeft om deze run op te kunnen starten. Toch is het advies om dit "op een rustig moment" te doen en wel op een moment dat de Replikatie PC "bij" is. Met andere woorden, als de Replikatie PC een achterstand heeft van een uur, is het niet slim om deze run op te starten, want Profit heeft méér Transakties dan dat er al gerepliceerd zijn; de SQL Server Database loopt dus a.h.w. sowieso al achter... Toch proberen we ook hier zoveel mogelijk ellende te voorkomen, bijvoorbeeld door de Transakties voor records die nog niet door de Replikatie PC zijn opgepakt niet te verwerken.
Ook is het advies om deze run niet gelijktijdig op te starten met het werkstation waarop de Replikatie zelf draait. In de voor ogen liggende opzet is er sowieso maar één werkstation in het netwerk welke verbinding heeft (vanuit Profit) met de SQL Server Database, en dat is de PC waarop de Replikatie draait. Deze tool is in hetzelfde menu opgenomen waarin de Replikatie zelf wordt opgestart; zodra op de Replikatie PC het Replikatie proces wordt stopgezet, kan direkt deze tool worden opgestart.
Restore SQL Server Database of Database Upgrade verzuimdDeze tool zou ook gebruikt kunnen worden i.g.v. bijvoorbeeld een crash van een SQL Server Database. We zouden kunnen besluiten om de Backup van de SQL Server Database van afgelopen vrijdag terug te zetten, om daarna alle records die ná het moment van die backup in Profit zijn gemuteerd, opnieuw te synchroniseren naar deze van de backup teruggehaalde SQL Server Database.
Een ander scenario waarin de tool uitkomst kan bieden, is als we de Replikatie na een Upgrade hebben herstart, maar verzuimd hebben om een Database Upgrade op de SQL Server te hebben gedaan; INSERT of UPDATE Queries kunnen dan fout zijn gelopen omdat de SQL Server Database nog niet over de juiste velden beschikt. Het opnieuw rechttrekken verwerkt dan deze Transakties nog een keer, en zorgt er voor dat de SQL Server Database gelijk wordt gemaakt aan de ADS Database.
Niet via nieuwe TransaktiesHet 'rechttrekken' van de SQL Server Database met de ADS Database wordt getriggerd door Transakties, maar maakt zelf géén Transakties. Met (voor alle tabellen) ongeveer een miljoen transakties per dag zouden dit er teveel worden, c.q. zou de Replikatie PC meteen een gigantische achterstand hebben als ze dit van een aantal dagen 'opnieuw' moet doen. Ieder record welke sinds de opgegeven datum 'geraakt' is, wordt één keer gesynchroniseerd met de SQL Server Database, ongeacht hoevaak het record in Profit is gewijzigd. Met als uitgangspunt dat deze run wordt opgestart zodra de Replikatie PC "bij" is (lees: geen transakties meer te verwerken heeft) geldt dat het record in de SQL Server Database gelijk mag worden gemaakt aan wat er nú in de ADS tabel staat. Komt het record meerdere malen in de SQL Server Database voor, dan zal zullen al die versies worden vervangen door één nieuw record met daarin de aktuele gegevens.
Ik kan de run maar één keer opstarten?Klopt. Na de uitvoering van deze funktionaliteit wordt de data in de Listmover controls bewust niet ververst. De data blijft staan, opdat de Gebruiker, als de run eenmaal klaar is, door de resultaten kan scrollen om te kijken hoeveel records er van welke tabel zijn verwerkt. Wilt u een nieuwe run opstarten, dan dient u éérst het scherm te verlaten en deze opnieuw aan te roepen. Om te voorkomen dat de Gebruiker een tweede maal op F1 drukt zonder dat de gegevens ververst zijn, worden alle toetsen waarmee tabellen tussen de linker- en rechter List kunnen worden verplaatst van het scherm verwijderd.
