Om strömmen går/systemet kraschar kan det bli både det ena och det andra.
Föreställ er att man har ett objekt som äger massa andra objekt, t.ex. en order med orderrader. Om man i laddar ordern och ändrar på orderraderna så måste man ju när man sparar (om man inte har det så att det ändrar sig dirket) ta bort alla orderrader för den ordern och sedan lägga till de aktuella raderna. Det finns massa exempel på liknande scenarion.

Men tänk om strömmen går mitt i allt. Vad gör man då. I exemplet med orderrader har man kanske en ordersumma i ordertabellen för att slippa räkna ut den varje gång man behöver summan. Den summan får ju helt fel värde.

Hur många av er brukar tänka på såna saker. Och vilka lösningar har ni? Pellesoft måste ju vara väldigt förberett på att systemet går ner när som helst.

Skulle vara intressant att veta hur ni gör.

/Jörgen

När strömmen går så är det bra att ha en UPS så man kan hinna spara allt och stänga av datorn

Många kör med datorn med hjälp av UPS när strömmen har gått men det är fel för en UPS klarar bara under en viss tid (Bero på hur mycket som är kopplad till den och vad den klarar av). Under den tiden ska man se till att stäng av datorn så inga fel uppstår.


Visst kan man ha tur att strömmen bara försvinner några minuter men hur vet man det :)

1) man ska inte lagra ordersumman i själva ordern , det är redundant

2) använd transaktioner när du skriver , går strömmen så behöver du inte bry dig eftersom ordern inte commitats in i databasen..

skulle man av någon anledning råka använda en db som inte stödjer transaktioner (tex här på jobbet kör vi med wm-datas "raindance" som är ett J#### skitsystem)
sp kan det vara en ide' att ha flaggor i sina poster

så att man när man är klar med inskjutningen av orderrader kan flagga i orderhuvudet att allt är klart. (och på så vis få en funktion som nästan nästan är som en transaktion iaf)

//Roger

Håller med att man skall använda Transactioner. Det skall man i princip alltid göra om man gör 2 eller fler förändringar som är beroende av varandara.

Däremot så håller jag inte med om att ordersumman inte skall sparas i Orderheadern. Och det beror helt enkelt på att priset på artiklarna som man har köpt kan förändras, och om man hela tiden räknar fram ordersumman så kan man få olika värden vid olika tillfällen, och det är inte bra.

- Magnus

<b>Däremot så håller jag inte med om att ordersumman inte skall sparas i Orderheadern. Och det beror helt enkelt på att priset på artiklarna som man har köpt kan förändras, och om man hela tiden räknar fram ordersumman så kan man få olika värden vid olika tillfällen, och det är inte bra.</b>

Av den anledningen bör man väl spara priset på varje orderrad och sedan beräkna summan för hela ordern när man behöver det?

/Johan

> 1) man ska inte lagra ordersumman i själva ordern , det är redundant

Det är inte säkert, du kan vilja ha möjligheten att sätt fast pris på en order, det är rätt vanligt till och med...

> man ska inte lagra ordersumman i själva ordern , det är redundant

Det var bara ett exempel, men iallafall. Ifall ordersumman inte ska användas så mycket så är det helt klart bättre att ha orderradens pris på varje orderrad (det ska man förstås ha iallafall). Jag tänker mig att iallafall - ifall man använder ordersumman ofta så blir det väl ganska mycket trögare i helheten.
Det är självklart på ett sätt bäddat för problem ifall man lagrar ordersumman. Men om man ser till att ordersumman räknas ut där det ska så borde det inte vara nåt problem.

Nåja ordersummor är ju inte så komplexa. Men ofta stöter man på tillfällen då väldigt komplexa uträkningar ska göras utifrån data, och då kan det verkligen vara prestandaökning om man gör de uträkningarna varje gång datan ändras, än varje gång man behöver uträkningen.

Transaktioner. Ja, det tycker jag som sagt är en självklarhet. Men kan man lita på att databaserna klarar av en systemkrasch? Jag antar att de större är pålitliga.

/Jörgen

det var ju det jag menade, men inte lyckades få ur tangentbordet... *gråter*

Men visst bör man spara priset på orderRaden.

- M