Indien de module
Profit-Transact is geļmplementeerd, zal iedere mutatie in een Tabel (die Transaktioneel gemaakt is) leiden tot een zgn. Transaktie. Een Replikatie Processor, een werkstation welke zich dedicated bezig houdt met het repliceren van deze Transakties naar een SQL Server, bezoekt het gemuteerde record opnieuw, bepaalt wat er gewijzigd is t.o.v. de vorige keer, en synchroniseert deze wijzigingen met de SQL Server Database.
Als deze Replikatie PC wil detecteren wat er gewijzigd is, zal het gewijzigde record nogmaals bezocht moeten worden, om vervolgens de huidige stand te vergelijken met de stand t.t.v. de vorige situatie. Het kan echter voorkomen dat het record nog steeds in gebruik is, waardoor de Replikatie PC niet veel anders kan doen dan wachten tot het record weer beschikbaar komt. Doorgaan met het volgende record mag niet, immers, dat zou resulteren in een inconsistentie database; we zouden bijv. wel onze Verkooporderregels terugvinden in een SQL Server Database, terwijl de Verkooporderheader (die eerder aangemaakt is) nog niet gerepliceerd is omdat we haar hadden overgeslagen. Dat mag dus niet.
Er zijn een aantal processen waarbij een Gebruiker langere tijd zo'n record in gebruik kan houden. Een voorbeeld daarvan is Hoofdmenu3-1-1 Toevoegen Verkooporder (LOVOTV). Aldaar kunnen we een Verkooporder toevoegen, omdaarna meerdere Verkooporderregels op te kunnen nemen. Gedurende het toevoegen van deze regels zal de orderheader gelockt blijven. Dit zorgt er dan voor dat de Replikatie-PC stopt met het repliceren, tot de Gebruiker klaar is met deze order. Als dat 15 minuten duurt, loopt de Replikatie dus feitelijk al meteen 15 minuten achter...
Dat een Replikatie een achterstand oploopt is vervelend als de data wordt gerepliceerd naar een SQL Database die gebruikt wordt om allerlei SQL Query's en Rapportages op los te laten, immers, die zijn dan niet 'aktueel'.
Het probleem is op zich vanuit Profit oplosbaar, door het werkstation welke de mutatie doet, direkt te laten bepalen wįt hij precies gewijzigd heeft; op die manier hoeft de Replikatie PC het record niet meer opnieuw te bezoeken om te kijken wat er gewijzigd is, dat is dan al bepaald.
Strikt genomen zouden we dat bij iedere mutatie op die manier kunnen afhandelen, maar, dat doen we vooralsnog niet. Conform de oorspronkelijke opzet was het juist de bedoeling om die wijzigingen zoveel mogelijk door die Replikatie PC te laten uitvoeren, opdat de snelheid waarmee de Gebruiker zijn orders kan invoeren zo min mogelijk wordt beļnvloed door het moeten bepalen wat er gewijzigd is.
Voor een aantal 'storende' situaties kunnen we dit probleem alsnog 'handmatig' in de coding ondervangen. Met deze Releasenote is dat voor de volgende situaties ondervangen:
* Toevoegen Verkooporder (Hmenu-3-1-1).
* Toevoegen-/Wijzigen-/Verwijderen Verkooporderregels
* Inlezen Verkooporderregels vanuit een Excelsheet (Hmenu-9-8-6).
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| LOEDVOZB | Genereren Verkooporder EDI | 29-11-2005 | 01-10-2019 |
| LOEOOS | Opschonen i.v.m. 2 GB - Verwerkte EDI berichten | 29-12-2017 | 01-10-2019 |
| LOEORA | Raadplegen EDI-Berichten | 20-06-2016 | 01-10-2019 |
| LOEOSF | Omschrijving (nog) niet bekend | 17-04-2012 | 01-10-2019 |
| LOKOTVED | Omschrijving (nog) niet bekend | 20-04-2018 | 01-10-2019 |
| LOLGWS | Omschrijving (nog) niet bekend | 22-05-2017 | 01-10-2019 |
| LOVOIMSQ | Importeren Verkooporders vanuit SQL | 03-10-2018 | 01-10-2019 |
| LOVOTV | Toevoegen Verkooporders | 26-09-2019 | 01-10-2019 |
| LOVOTVED | Omschrijving (nog) niet bekend | 27-06-2017 | 01-10-2019 |
| LOVRM3T2 | Invulllen Matrix Verkooporderr | 12-10-2011 | 01-10-2019 |
| LOVRTVF1 | Omschrijving (nog) niet bekend | 25-09-2019 | 01-10-2019 |
| SYSS | Omschrijving (nog) niet bekend | 25-09-2019 | 01-10-2019 |
| SYT | Omschrijving (nog) niet bekend | 30-07-2019 | 01-10-2019 |
| SYTVBW | Omschrijving (nog) niet bekend | 30-07-2019 | 01-10-2019 |
