RohitPatel9999 wrote:
> FoxPro supports row level locking. Ofcourse FoxPro creates one file for each
> table. There must be some way to implement row level locking. Probable by
> locking region in a file or somehow.
>
> Just thinking curiously...how MS could have implemented row level locking in
> FoxPro.
>
FoxPro (DBase-III file structures) is a piece of shit that corrupts
all the time. NEVER run FoxPro on a novell network with Win95 clients
(ok, so this was last decade). FoxPro does region locking and has NO
JOURNAL. "Rollbacks" are done by the client by replacing the changed
rows. If the client crashes with a table (or table set) partially
modified, then the table is left inconsistent. FoxPro is not ACID.
At my previous employer I wrote some C code to repair broken foxpro
tables. (I myself did not write foxpro code). Our main database at
that time was 5 large tables, each about 256M in size. All sitting on a
single Novell share. Every few days a win95 or win98 client (100
clients, all using IPX, novell v3 on HUBS (not switches)) would send a
junk packet to the server. (or it sent a good packet that arrived
mangled). From my analysis of the corrupted database file, it seems
that the client intended to send a "seek (somewhere far down in the
file)" and then "write". But what actually happened is that the Novell
server seeked to file offset 0 (btw, the metadata for the table) and
dutifully wrote out the data record. So instead of the DBF (foxpro
table) file having the proper header that defines the record layout for
the table, it contained junk. The FoxPro guys had no way to fix this
except to try to restore from a backup and re-run tens of thousands of
"transactions". So one day this happened and the CIO was freaking out.
I pulled up a file format spec for the DBF file and fixed it using a hex
editor. Later that day I wrote a tool to repair the damaged header. A
fun hack, but a horrible situation and horrible technology.
The moral of the story is that you should never trust a database
system that does region lock of flat files sitting on a server IF the
server will release the lock when the client dies AND the client does
not leave behind some sort of useful journal. Maybe even this statement
is too liberal. I'm sure that someone in this group can make a better
argument for never using region locking.
Moral #2 is that creative use of hex editors in front of the CIO can
help your career. Unless he's a total spaz and doesn't understand what
you are doing.
