Suppose I’m working in a client machine and accessing the Server Nav database. I’m entering data in the PO/SO or any journal entry form in NAV. At that moment my client pc shutdown suddenly
Will it create any DATA CORRUPTION in the DB?
How can we understand that there is a corruption in the data or not?
I assume you are talking Native database published through a Nav database server. This does not access the database directly from the client PC so cannot corrupt the database. The native database uses a versoning principle so will “Rollback” or not commit partial data. If a PC shuts down then all that is lost is the transactional data being entered/processed at the time.
To test for data corruption do a full database test. Data corruption is completely different to incorrect data on the table(s).
… and the same applies to SQL Server, too - of course. Well, with SQL there is no “Version Principle” as in C/SIDE, but its Transaction Log mechanisms also grant transactional integrity, thus SQL would also roll back any open transactions in case of a sudded process kill.
And: actually a database - C/SIDE or SQL - could get corrupted especially if the disk-subsystem suddenly fails. In such a case data, which might be cached by the disk-controller (write-cache) is flushed and not properly saved. The DB Server is not aware of this and cannot roll back, thus the physical integrity is lost.
If using the COMMIT CACHE with native C/SIDE Server, the risk is the same: data is marked as “committed” even though it is only stored in the cache/RAM, without being saved to disk. If the CC is flushed - sudden shut down or failure - this data is never transferred to disk; the database is corrupt.
If the physical DB integrity is lost you usually cannot repair this! You need to restore the latest backup …
Hence, it is crucial to have stabile/reliable Server machines and storage systems. Using caches would remarkably improve the performance (thus recommended), but you need to make those systems as failsafe as possible; e.g. using battery buffers, independent power supplies, etc…
The whole reason for calling it a commit cache is because it controls the commiting of data to the disks. Slave.exe controls that data is written to disk in the correct sequence, and the Btree is kept in balance. So if the commit cache crashes (say due to a power failure) then the data that has been written will be consistant, and thus the database will NOT be corrupt. You will of course lose any work that was still in the commit cache. Which is why Navision allways recomend that the commit cache has a battery backup, since the 600,000 Meg can hold a lot of work that you don’t want to redo.
And Commit Cache is not “flushed” to disk. That would be something like write cache on a harddisk controller that can do exactly what you describe above. Commit Cache respects the Version Principle.