|
Title: Replicate - inzetten Listview control Post by: Heart Informatisering B.V. on June 23, 2016, 03:55:45 pm De interne werking van Replikatie Processor is m.i.v. deze Releasenote opnieuw opgezet.
Het hoofdscherm van de Replikatie Processor is ooit gebaseerd op het hoofdscherm van de Batch Processor, doch, daardoor zijn een aantal zaken meegekopieerd die bij de Replikatie niet worden gebruikt. De Replikatie is m.b.v. de volgende punten gewijzigd: * Met de kopie van het Batch Processor scherm is er een Listview control meegekopieerd die vanuit de Replikatie nimmer gevuld werd. Deze Listview control leent zich er juist voor om diverse informatie aan de Gebruiker te melden, zoals 'met welke stap in het proces de Replikatie bezig is'. In de nieuwe versie wordt nu deze Listview aangestuurd. * Onderdeel van de Replikatie is dat een bepaalde retentietijd (ingesteld op 5 dagen) de SQL tabel SYWT wordt opgeschoond. SYWT bevat de informatie van de te updaten records voor- en na het bezoek van de Replikatie Processor, en gebruikt deze informatie om (eenmalig) te bepalen welke gegevens er gewijzigd zijn en gerepliceerd moeten worden naar de SQL Server. Het opschonen van deze tabel gebeurde per Transaktie Datum + Tijd, en kon op die manier in vele duizenden SQL opdrachten resulteren om de tabel op te schonen. Hoewel dit opschonen ook met 1 SQL opdracht zou kunnen volstaan, gebeurt het opschonen nu met 1 opdracht per op te schonen datum waardoor dit proces vele malen sneller geworden is. De Listview control toont tevens van welke datum de gegevens worden opgeschoond. * Met een verbeterde opzet door het gebruik van Timers kan de Replikatie Processor nu ook momenten hebben dat ze echt even "niets" te doen heeft; in de oude situatie werd iedere keer als ze niets te doen had, het "Opschonen" aangeroepen (welke funktionaliteit maximaal 1x per dag aangeroepen hoeft te worden, omdat ze toch alles op dagniveau opschoont). * Eveneens gekopieerd uit het Batch Processorscherm waren de Stopdatum-/tijd, bedoeld om de Processor te kunnen stoppen t.b.v. de Backup. Het feit dat deze datum-/tijd in het scherm was opgenomen leek te impliceren dat ze ook gebruikt werd, maar niets blijkt minder waar te zijn. De Replikatie Processor respekteert niet die setting, maar wordt aangestuurd via een zelf te maken Backupscript die vlak voor aanvang van de Backup in de FOXLOLOPW directory een file BACKUP.TXT dient aan te maken, en deze file weer dient te verwijderen als de Backup klaar is. De Replikatie Processor stopt dus als die file gevonden wordt, en gaat verder als de file verwijderd is. Omdat de Datum-/tijd rubrieken niet gebruikt werden, zijn deze nu van het scherm verwijderd. Tijdens het wachten tot de Backup klaar is wordt het scherm nog maar eens per 5 minuten geupdated. * Middels een oplopend tellertje 'wacht op transaktie' iz zichbaar dat de Replikatie staat te wachten, maar geen te verwerken transakties aangeboden heeft gekregen. Het tellertje reset zodra er transakties gerepliceerd worden naar de SQL Server. Met een 2e tellertje wordt getoond hoeveel Transakties er gerepliceerd zijn naar de SQL Server sinds het opstarten van de Replikatie Processor. * De Replikatie bezoekt alle gemuteerde records uit Transaktionele tabellen, bepaalt wat er gewijzigd is en repliceert de nieuwe data naar de SQL Server. Regelmatig komt het voor dat de Replikatie staat te wachten op 'Gevraagde gegevens zijn geallokkeerd', immers als een gebruiker een Verkooporder toevoegt, zal ze daarna die order gelockt houden tijdens het proces 'Toevoegen VO Regels'. Soms wil het ook voorkomen dat de Replikatie onnodig lang op zo'n melding blijft staan, simpelweg omdat ergens in de wijze waarop de Gebruiker zijn handeling verricht heeft er een record niet wordt vrijgegeven. Wie de gevraagde gegevens in gebruik heeft is dan veelal de vraag en het kost veelal moeite om iemand gericht aan te sturen met 'geef jij eens even expliciet gegevens vrij'. Hoewel niet waterdicht, geldt dat in de meeste gevallen het door de Replikatie bezochtte record geallokkeerd zal zijn door de gebruiker die de Transaktie aanmaakte, en die is bekend. Nu ook een Listcontrol is geaktiveerd, wordt die Listcontrol nu gevuld met het Userid van de Transaktie. Om de Listcontrol niet onnodig te vervuilen wordt niet iedere lockfout gemeld, maar enkel "de 25e".
|