Power Surge during Posting of a transaction

The source of problem can be some customization. It seems like COMMIT during process, which should be "ATOMIC".

Hmm... That's funny, I thought one of the selling points in Navision was the rollback feature if there's an event like this. :-k

deadlizard wrote:

Hmm... That's funny, I thought one of the selling points in Navision was the rollback feature if there's an event like this. :-k

The rollback does work for the old state of one or more tables before the transaction (xrec) and the state after the transaction (if it isn't a hardware issue, but this will often end up in a corrupted database). Despite of this, usually more than one table is modified during a posting procedure. If a COMMIT is somewhere in the code after the first lot of tables are modified ( this will end the first transaction and start the second transaction), and then the power failure occurs while the second half of the posting procedure takes place, the second lot of tables will not be modified. Their new state (rec) is rolled back to the state they had before the second transaction started (xrec).

Basically there are two things that could cause an error during a power failure the first is baddly written code (as mentioned above), i.e. a COMMIT where it shouldn't be.

Before I go any further, please understand that there is no such thing as Rollback in Navision, Navision uese a version principle, so don't confuse this with a rollback.

The second (And YES I have seen it happen) is when a system is installed using the wrong hardware, specifically two things, write cache or RAID 5.

By the way (sorry Luc O:) ) even if you use COMMITCACHE, and have no UPS, a power failure will NOT corrupt the database. The version principle works exactly the same in commit cache or on hard disk, in that data written from the server to cache to hard disk is written in the same sequence, and the vesion is not updated until the last word is commited, and the version pointer changes. So even if half the data was on hard disk, and half in commitcache, the database will still be consistant.

Now everybodys favourite... RAID 5. One of the things that RAID 5 (I think the same goes also for RAID 3, but I am not vertain) does is it inteligently interprets data being written to disks to make sure that the data is sent to the correct disks, so each byte is broken in half, a 4 bit check sum is created, and these bits are spread over disks. All nice and simple, BUT these days we don't look at data in 8 bit chunks, we start with words or long words, and we grab a lot of them at once. So what can happen is the controller takes (say) 1k of data scrambles it optimizes it, and then works out where to put that data ont he disk for optimium reading later on. Then it goes and gets the next 1k and does the same. Well since naveion is not working in 1 k blocks, its very possible, that during a transaction, the word containing the COMMIT of a current version goes on a track where the heads are now, even though other data has not been written yet. Then if the system fails, when Navision starts up again, it has the latest version pointer on hard disk, but not all the data has been written. Now when this happens, the most common thing is to see the "Corrupt database" (Navision's grey screen of death), but sometimes, the data is valid, just wrong. Thus you have corrupt database.

The correct way to fix this is to restore a valid backup.

As mentioned there is also C/DART (Client / Data Recovery Tool). This extremely simple tool just gives you a list of pointers. You can then select one, and roll back the database. You loose the last transactions, but you gain a valid database. Also DART will give you information about whether that version snapshot is valid or not.

The problem is that Dart is not accessible outside of Microsoft, and you really don't have time for that, best is to always have a good backup plan.

By the way, if this was a RAID 5 or a Write Cache error, then be aware that these are very very rare, and you probably just got unlucky. More likely is a COMMIT written where it shouldn't be.

PS did I mention that I don't like RAID 5?