De linjene du har markert med rødt, er nok en den av den innledende kontrollen før buntoppdateringen egentlig starter - det samme som skjer når du bruker behandlingsvalget Valider bunt. Her blir hver bilagslinje validert for seg. Har du en bunt med to hundre bilagslinjer og det står Prosjektnr 4711 på alle linjene, så sjekker VBus at Prodsjektnr 4711 finnes 200 ganger. Ikke egentlig smart. Det samme skjer på alle de andre ansvarsenhetene også. Og slik er det fremdeles i versjon 18. Men det som egentlig tar tid, er at VBus låser saldo-tabellene eksklusivt for hver bilagslinje som skal oppdateres. Du finner igjen disse i loggen som SELECT * FROM AcBal [TABLOCKX] WHERE AcNo=0. Jeg har stusset over dette, for det finnes ingen rad i saldo-tabellene med Kontonr=0. Men det et TABLOCKX som er det vesentlige; Lås hele tabellen inntil COMMIT TRANSACTION. Dette gjør at det ikke har noe hensikt å sette opp flere jobber som oppdaterer bunter samtidig; alle skal gjennom den samme slusa. Dette blir muligens løst i versjon 18.10 som kommer i desember. Det ble løst i NXT nå i oktober. Det vil si; det introduseres en mulighet til å oppdatere bunt uten samtidig å oppdatere saldo-tabellene. Og et menyvalg som heter, oppdater bunter som er bokført siden forrige saldo-oppdatering. Men det er nok bare de med meget høyt transaksjonsvolum som kommer til å nyttegjøre seg dette.
... View more
.gif "VISMA"){kind=icon}
Visma Denmark
Visma Finland
Visma Latvia
Visma Netherlands
Visma Norway
Visma Sweden
Visma Developers & Partners
Visma Latin America