Bij aanwezigheid van de module
Profit-Transact leidt iedere wijziging in de database tot een zgn. Transaktie. Deze Transaktie wordt vervolgens gebruikt om een gekoppelde SQL database v.w.b. het gewijzigde record te synchroniseren met de Profit-Database (Replikatie). Er kunnen ook andere doeleinden zijn waarvoor iemand met Transakties wil werken, maar voor dit onderwerp houden we "de replikatie naar een SQL Database" even als reden aan.
In principe kan van iedere Tabel in Profit worden aangegeven of deze Transaktioneel is of niet. Transaktioneel kun je lezen als "of de wijzigingen in de Profit-Database v.w.b. deze tabel moeten worden doorgekopieerd naar de SQL Database". Normaliter geldt dat als we én een Profit-Database hebben én een SQL-Database, we deze altijd aan elkaar gelijk willen hebben, en dus de gegevens 1:1 moeten worden gerepliceerd naar de SQL Database.
Waarom zouden we het niet doen ?
Wel, de voornaamste reden om gegevens niet door te kopiëren naar de SQL Database zal "performance" betreffen. Transakties moeten immers verwerkt worden, en dat kost tijd. Hoeveel tijd, hangt van diverse faktoren af. Ook varieert het aantal te verwerken Transakties wat welke handelingen U in het systeem uitvoert, en hoe vaak. Het mag duidelijk zijn dat iemand die 1000 Verkooporders op een dag heeft, meer Transakties te verwerken heeft dan iemand die 1000 Verkooporders op jaarbasis heeft. Wat zeker ook niet onbelangrijk is, is het tijdsbestek waarbinnen e.e.a. verwerkt moet zijn. Stel dat er via een webshop Verkooporders geplaatst worden, en de klant wil zijn eigen order (die in de Profit-Database binnenkomt) op de webshop terug kunnen vinden, dan moeten de mutaties in de verkooporders, verkooporderregels etc. wel snel genoeg repliceerd worden naar de SQL database.
Als we het in zo'n situatie over een klant hebben die ook 10.000 boekingsregels op één dag produceert, dan kun je je afvragen of je "Boekingsgegevens" wel wilt repliceren naar de SQL Database, immers, het kost tijd om e.e.a. te verwerken, en als niemand iets met die financiële bestanden doet in de SQL database, is dat zonde van de tijd. Derhalve kan per tabel worden aangegeven of deze Transaktioneel is of niet.
Merk op dat aanpassingen aan deze Transaktioneel status altijd "in consistentie" moet gebeuren, en dat dergelijke instellingen vaak in overleg zullen gebeuren met een consultant van Heart. Bedenk maar wat er gebeurd als Verkooporderheaders wel transaktioneel zijn, maar Verkooporderregels niet, en dán een klant via een webshop een order plaatst.
Een Tabel is Transaktioneel (of niet). Maar in één Tabel wordt data weggeschreven van meerdere Bedrijven. En, wederom geldt ook op dit niveau dat we binnen Profit weliswaar 5 bedrijven administreren, maar dat slechts één van die 5 in de SQL Database gebruikt wordt. Derhalve is het ook mogelijk om
per Bedrijf aan te geven of de gegevens uit dat bedrijf naar de SQL Database moeten. Met die optie kan e.e.a. voor een heel bedrijf ineens worden uitgeschakeld (wat dan vanzelfsprekend alleen effekt heeft op de Tabellen die überhaupt Transaktioneel zijn).
Binnen Profit bestaat er funktionaliteit om een Profit-Tabel (opnieuw) in zijn geheel (of v.w.b. de records van één specifiek bedrijf) te uploaden naar de SQL Database. Deze funktionaliteit zal in ieder geval bij aanvang met een SQL Database worden gebruikt, maar kan ook halverwege een keer worden gebruikt.
Zo af en toe komt het nog wel eens voor dat er een proces wordt opgestart waarbij er heel veel Transakties worden gegenereerd. Dit kan te maken hebben met een proces welke door een gebruiker wordt opgestart, het kan echter ook te maken hebben met bijv. een Upgrade. Neem maar eens als voorbeeld het Afleveradres 999 welke recentelijk is verlengd tot 9999. Het Afleveradres 999 werd gebruikt als Algemeen Afleveradres, en sinds die aanpassing moest 999 worden gewijzigd in 9999; en dus ook in de bestaande database. Wel, als je dan 1000 orders per dag hebt, zijn dat er zo'n 365.000 in een jaar, en kun je je voorstellen dat e.d. konversie al snel enkele honderdduizenden Transakties oplevert voor de tabel "Verkooporders".
Zo ook komt het wel eens voor dat iemand "Reset Mutatiebestanden" doet in de Testbestanden, of in de bestandenset van een Testbedrijf wiens gegevens we niet op de SQL nodig hebben, en daarmee duizenden Transakties genereert voor een bedrijfs-id waar we niets mee doen in de SQL Database.
Een ander voorbeeld is dat het heel af en toe voor komt dat een index beschadigd raakt door een storing. De index kan opnieuw worden opgebouwd door de tabel te reorganiseren, echter, de tabel kán niet gereorganiseerd worden als er nog openstaande Transakties voor die tabel bestaan.
En hoewel Profit dus al wel beschikte over funktionaliteit om een specifieke tabel opnieuw te uploaden naar de SQL Database, waarmee een Systeembeheerder zelf een probleem zóu kunnen oplossen zonder dat Heart daarbij benodigd zou zijn, was toch veelal de hulp van Heart nodig om de openstaande Transakties uit het systeem te verwijderen.
Per heden is er een funktie ontwikkeld waarmee een (voor deze funktionaliteit geautoriseerde) gebruiker in staat wordt gesteld om nog niet verwerkte Transakties te verwijderen. Doel van deze funktie is de gebruiker een tool te bieden waarmee ze zelf zaken kan korrigeren waar ze anders ons voor nodig had. Met deze tool is de gebruiker dan ook in staat dit soort problemen te verhelpen buiten kantooruren om.
De funktionaliteit is te vinden bij Hoofdmenu-9-5-7-4-3.
Middels een 3 tal Comboboxen kan worden gefilterd op de te verwijderen Transakties, met als eerste selektie "Produktiebestanden / Testbestanden / Systeembestanden".
Op basis van de "Produktie-/Test" instelling worden vervolgens de 2 Comboboxen "Tabel" en "Bedrijf" opgebouwd, en gevuld met die gegevens waar ook daadwerkelijk nog openstaande transakties voor bestaan.
Het is aan de gebruiker om te beoordelen welke gegevens wel/niet verwijderen kunnen/mogen worden, c.q. of er nog aanvullende akties vereist zijn.
Om even een voorbeeld te geven: we administreren bedrijf A, B, C en D. Alleen bedrijf C gebruiken we ook daadwerkelijk in de SQL Database i.v.m. een koppeling met een webshop. Iemand genereert in bedrijf A (welke zo staat ingericht dat ook deze naar de SQL database gaat, ook al hebben we die gegevens eigenlijk niet nodig in de SQL Database) een heleboel transakties, waardoor we in bedrijf C moeten wachten tot die transakties (waar we toch niets mee doen) verwerkt zijn. In zo'n geval kan deze funktie worden gebruikt om
alle Transakties van bedrijf A te verwijderen.
Let op: Met dat je dit voor bedrijf A wel wilt kunnen doen, kun je het ook voor bedrijf C doen, terwijl dát zou impliceren dat alles wat nodig is om de SQL Database te synchroniseren met de Profit-Database, v.w.b. bedrijf C geëlimineerd wordt, en de Profit-Database dus niet meer synchroon loopt met de SQL Database. Niet doen dus !
Tsja... tenzij ook iemand voor bedrijf C in gedachte heeft dat ná het verwijderen de hele Profit-Database opnieuw naar de SQL geupload wordt, immers, dan zou het weer wel mogen.
Een voorbeeld op Tabelniveau is al gegeven: het Afleveradres 999 welke naar 9999 gekonverteerd is, en tot honderdduizenden transakties leidde in de tabel LOVO. Middels deze run zou de gebruiker kunnen besluiten om alle openstaande Transakties voor LOVO te verwijderen, om vervolgens de tabel LOVO in één keer helemaal opnieuw te uploaden naar de SQL Database (wat dan natuurlijk wel moet gebeuren, anders is de SQL Database alsnog niet up to date).
Een selektie is verplicht. Het is niet toegestaan om zowel Tabel als Bedrijf leeg te laten. Die selektie zou impliceren dat alle openstaande Transakties moeten worden verwijderd, ongeacht Tabel en ongeacht voor welk bedrijf. Natuurlijk kunnen we ook voor die situatie wel een nuttig voorbeeld verzinnen, maar het is dermate gevaarlijk dat dit mis gaat (omdat een gebruiker klakkeloos op F1 drukt) dat we voor dié wens gewoon stellen "dan verwijder je maar per bedrijf alles, en doe je dat 4x als je 4 bedrijven hebt".
Op zich is het wel logisch... Transakties van Bedrijven waarmee we niets doen in de SQL Database mogen zonder meer verwijderd worden. Het enige wat er dan gebeurd is dat die Transakties niet meer doorgekopieerd worden naar de SQL, maar, we doen er toch niets mee. Eigenlijk hadden we beter het Transaktiemechanisme voor dat bedrijf kunnen uitschakelen, hetgeen we alsnog kunnen doen, zonder iets te missen in de SQL Database.
Transakties van Tabellen/Bedrijven waarmee we wél wat doen in de SQL mogen in principe
nooit worden verwijderd, tenzij de betreffende tabel opnieuw naar de SQL Database geupload wordt. Bij het verwijderen van de gegevens uit één tabel is het vanzelfsprekend welke tabel opnieuw geupload moet worden. Bij het verwijderen van gegevens op basis van de bedrijfs-id, geldt dat die informatie uit alle tabellen wordt verwijderd, en dus zouden alle tabellen opnieuw geupload moeten worden. Met deze kombinatie dus erg oppassen!
Om te voorkomen dat niet iedereen deze funktie zomaar kan uitvoeren, is expliciete toegang tot Funktie "SYUTOTVW" vereist.
