The Curse of Table/Index Corruption!!!

Quote (Adam Johnston) wrote:

>This is a problem that has been pissing me off for years in other
>database languages as well as Delphi and I still don't know a way
>around it.

>What happens when you have been writing records to a table and indexes
>have been updated and suddenly there is a power failure or Windows
>locks up completely and you have to reset - Table/Index corruption
>and/or all posts made since the file was open are lost.  

>How do you ensure that when you post a record that it actually goes to
>disk and that its not sitting in memory other than closing the files
>and reopening them?

>Currently I am having this problem with a mission critical D1
>application that must run all day long without fail.  It is running
>under Win 95 and occassionally everything locks up and they have to
>reset.  Sometimes this is OK but usually it screws the files up big

The problems described here have nothing to do with Paradox as such.
Visit the xbase newsgroups and you will see the same complaints about
Foxpro, Clipper etc.

For standalone systems, Borland should know better, and the
DbiSaveChanges methods should have been in the printed documentation
with the very first version of Delphi.

Furthermore the DbiSaveChanges routine does not work properly with
Dbase files. When the program crashes, you find empty holes in the
tables. The rows exists but no data shows, not even the record
numbers. This was the case with Delphi 1.0. I don't know if it has
been fixed subsequently.

 With Paradox and other flat file systems, each BDE running on every
user's machine accesses the tables individually through a file-locking
mechanism, just as with a Microsoft Word file or any other shared
file. Problems are bound to happen.

In a server system, users do not access the tables directly. They
communicate with a process running on the server, which actually reads
and writes the data. Thus there is no corruption. Xbase guys now have
Advantage, Alaska, etc. What do we Paradox guys have?.

When the Delphi 3 publicity spoke of remote datasets like IProvider,
ClientDatasets etc, I thought those problems will be solved, but alas,
it is only available with the Client Server version.

Anyway (to Team B) do these features actually work like a true server
(i.e. with Paradox/local tables), using a single instance of the BDE
on the server to read and update data, or does each client use a
separate session on the server?

One final thing, Borland, Microsoft et al, have no financial incentive
whatsoever to develop a rock solid, shared-file system, which is
freely distributable, with no royalties. They will always prefer and
recommend the Interbase and MS SQL Servers, where they charge $150 for
every user. After all if you managed to sell 1 million copies of your
whizz-bang application, what would they gain from you? Absolutely
nothing except some nice and begrudging statements about how great
development tools Delphi and VB/Access are.
remove no_spam_ on reply