On 1/5/2010 6:47 PM, Rony wrote:
The trick in tally is different.
In order to prevent accidental modification of previous year data, the tally data is split into different years. After audit and finalisation, the previous year's tally data is separated and put into a different file so the current year remains small and usable in any case.
That keeps the records slim and trim. :-) From a database maintainence point of view _if_ this method is good, it could be incorporated in gnukhata too. Even if a file is corrupted, it is only for that year. Can it be split further into months or weeks. Just like it is easier to prevent lost emails in Thunderbird or OE if the mails are spread over different folders (smaller db files). Just thinking aloud.
Its standard accounting practice that in this case, helps tally. In ERP environment, they have a process to lock the data of completed periods to avoid accidental changes.
Most of the real biggies use ERP
But i have used tally in a US$15 million export house (actually ran their accounts) and worked with another company Rs. 175 Cr multi-location shipping line who used tally purely till we moved them into erp. We used to have upto 3500 primary transactions and another 1500 secondary transactions each month in the export company.
What I've observed is that one cannot take any risk in doze as one can do in Linux. However if one is a careful and disciplined user, the systems run quite trouble free for years. It all depends on the usage.
Few of the SMEs run linux. All of them run tally on windows, so either they are all taking major risk, or the risks are over-stated. Ofcourse, we being a processing center had a practice of sending out backups to the client as a part of our end of day process