|
==> |
Tilbake til hovedsiden. |
==> |
Tilbake til oversikt over tips. |
|
I AGRESSO 5.5 Sp1 feiler ACRALS-prosessen på så mange tabeller at det ikke har noen hensikt å ha ACRALS-prosessen aktiv, men logging av endringer kan likevel være aktivert slik at disse blir tatt vare på i tabellene ACRAMENDLOG og ACRAMENDLOGSHD. Ved oppgradering til AGRESSO 5.5 Sp2 kan ACRALS-prosessen igjen aktiveres og med litt flaks går de gamle transaksjonene i ACRAMENDLOG og ACRAMENDLOGSHD gjennom. Typisk eksempel på "uflaks" er at man har lagt inn Update 6 til AGRESSO 55 Sp2 og det blant de utestående transaksjonene finnes transaksjoner av typen "DELETE" (change_status='D'). Dette er i hvert fall situasjonen dersom man kjører databasen på MSSQL og har slettinger i tabeller som AGLDIMVALUE (Begrepsverdier). Jeg vet ikke om det feiler for alle tabeller, men det er det mest sannsynlige. Feilen skyldes en syntaksfeil i SQL-ene, og jeg regner med at den blir rettet i Update 7. Slik ser dette typisk ut i loggen: 11:11:40 > ERROR 8155: [Microsoft][ODBC SQL Server Driver][SQL Server]No column was specified for column 14 of 'x'. 11:11:40 > ERROR 8155: Error in AGRExecSql: Couldn't execute statement when Insert 'D' data into aglshddimvalue SISTE: Dette er nå rettet av en HotFix fra Agresso !!! Et annet vanlig eksempel på "uflaks" når man skal ta igjen det forsømte er at ACRALS-prosessen låser seg selv i databasen. Dette har jeg foreløpig bare observert når man kjører databasen på MSSQL. Symptomet er at ACRALS-prosessen "henger"; gjerne veldig tidlig i prosesseringen. Ved nærmere inspeksjon i MSSQL ser du en SPID i Master..Sysprocesses som er blokkert av en annen SPID, der begge SPID-er har samme "HostProcess". (Begge SPID-er tilhører ACRALS-prosessen som henger.) Dersom denne situasjonen oppstår kan det være klokest å oppsøke hjelp. Situasjonen løser seg alltid med litt "massasje". Jeg midt oppe i en større sak av denne typen nå og vil komme tilbake
med flere erfaringer etter hvert. |
