Oslo, 6. april 2025
Endret 30. april 2025
Versjon 19.10 kom i slutten av forrige uke. Her er det en nyhet som er spennende for de som har integrasjoner med andre applikasjoner: Alle tabeller får tidsstempel for opprettet og endret. Dette har med seg både dato og kl.sl. med en presisjon på millisekund. De fleste av oss har neppe behov for et kl.sl. som er mer eksakt enn time og minutt, selv om noen nok har savnet sekund i feltet Endret kl. Men når applikasjoner «snakker» sammen, så kan det gå raskt i svingene og da kan det være nødvendig med helt eksakt tidsangivelse for når en endring har skjedd. Noen få tabeller (Aktør, Ordre og Ordrelinje) fikk kolonnen Endret tid i millisek. for en del versjoner siden, men nå får altså alle tabellene kolonnen Endret tidsstempel. Jeg vil anbefale alle som har en integrasjon hvor Endret dato og Endret kl. brukes til å ta stilling til hva som skal skje, endrer integrasjonen slik at Endret tidsstempel brukes i stedet. Og så er det en del som har triggere og/eller prosedyrer som endrer rader i forskjellige tabeller. For å unngå inkonsistens mellom Endret tidsstempel og Endret dato/kl. vil jeg på det sterkeste anbefale at alle triggere og prosedyrer gjennomgås med tanke på også å oppdatere Endret tidsstempel. Dette kan med fordel gjøres kart før oppgradering til (eller forbi) versjon 19.10 – og implementeres straks etter oppgraderingen.
Det hadde vært fint om de to nye kolonnene ble tildelt verdi ved oppgradering slik at vi ikke starter med inkonsistens. De nye kolonnene er blanke i alle tabeller rett etter oppgradering. Jeg har et skript som tildeler verdi basert på opprettet og endret dato og kl. for de som er interessert.
Merk at tidsstempel-kolonnene er UTC-tid, slik at kl.sl. ikke samsvarer med Opprettet og Endret kl.
DME-tabeller får ikke disse tidsstempel-kolonnene ved oppgradering. Men nye DME-tabeller får det – og verdier blir tildelt automatisk når rader legges inn eller endres. På eksisterende DME-tabeller er det mulig å legge inn tidsstempel-kolonner, men de tildeles ikke verdi automatisk. Og de regnes ikke som kontrollkolonner slik tidsstempel-kolonnene er på standard-tabellene og på DME-tabeller som opprettes i versjon 19.10. Det er selvfølgelig mulig slette de gamle DME-tabellene og opprette dem på nytt, men da må alle vinduene som bruker dem også endres – siden både tabeller og kolonner får nye eksterne nummer.
For de som er enda mer teknisk interessert: Det skjer en slags modellendring: Tidligere måtte kolonner med variabel lengde ligge bakerst i tabellen. Slik er det ikke lenger. Se her. Det er ikke mange tabeller som har slike kolonner. På stående fot kommer jeg bare på ordrevedlegg og endringslogg-tabellene. Releasenotes er litt misvisende her. Det står:
Prosessen for databaseoppgraderinger er forbedret. Tabeller trenger ikke lenger å opprettes på nytt når nye kolonner legges til, da nye kolonnene legges til på slutten av tabellene. Tidligere krevde Visma Business at kolonnene kom i en bestemt rekkefølge, dette er ikke lenger nødvendig.
Men det er fremdeles slik at DME-kolonnene må komme etter standard-kolonnene. Det betyr at ved oppgradering til (eller forbi) versjon 19.10 vil alle standard-tabeller med DME-kolonner først bli tildelt et nytt navn, så blir tabellene opprettet på nytt, alle rader blir kopiert fra gammel til ny tabell og gammel tabell blir slettet. Som før. Med den konsekvens at alle indekser som er opprettet på SQL-server (ikke via VBus) forsvinner. Og alle triggere forsvinner (bortsett selvfølgelig fra de som VBus oppretter selv). Jeg har skrevet noen prosedyrer som tar vare på alle indekser og alle triggere (som ikke er kryptert) og noen andre prosedyrer som legger indekser og triggere som mangler etter oppgradering tilbake i tabellene.
En annen konsekvens av at alle standard-tabeller får nye kolonner som plasseres før DME-kolonnene, er at oppgraderingen tar lenger tid enn det som er typisk. De fleste vil ikke merke noen forskjell, men de som har svært mange rader i transaksjonstabellene og samtidig har DME-kolonner i dem, vil merke at oppgraderingen tar betydelig lenger tid enn ellers. Sjekk om du noterte hvor lang tid databaseutvidelsen tok ved oppgraderingen til (eller forbi) 16.10, da mange tabeller fikk den nye kolonnen MemoNo. Du kan nok forvente at databaseutvidelsen til (eller forbi) 19.10 tar like lang tid.
Du kan lese om det som ellers er nytt her: Nyheter og forbedringer.
Resten av min blogg kan du lese her: frode.antun/VBus/blogg