Re: FoxPro Vs. PostgreSQL

Sai Hertz And Control Systems wrote:
> This was great help loads of thanks
> Now its upto me to convert it into laymans language.

Those limitations don't really describe what the real problems of FoxPro
are. I've used FoxPro since the days it was a product of Fox Corporation
so I know indepth all the issues.

The biggest problem: completely and absolutely multi-user unsafe. If two
machines try to update the same record and append to the safe table, one
of the following things may occur:
1) One machine gets stuck "waiting to lock" and never ever ever comes
back to life. 70%
2) FoxPro on one or both machines immediately crashes with a Windows
exception error. 25%
3) Indexes get corrupted 4%
4) A garbage record is inserted 1%

There is a way to solve the multi-user problem but it requires you to
write your own table/record locking mechanisms. Basically, if you try to
use FoxPro's RLOCK() or LOCK(), you are screwed. However, exclusive file
handles on a shared network drive seemed pretty solid. (My experience on
SAMBA, Netware and NT server -- dunno about Win98 file sharing though.)
You just suffer a huge performance penalty as file creation/directory
scanning incurs a high overhead. You also run the risk where if your
code doesn't release locks, nobody else could ever do any transactions
since they aren't auto released when a table is closed or a record
pointer moved.

Indexes also always get corrupted sooner or later whenever you exceed a
table size threshold. Corruption of indexes will exhibit the following
symptoms:
1) Searches get stuck in infinite loops 60%
2) Searches return the wrong results 30%
3) FoxPro crahses with a Windows exception error 5%
4) FoxPro just simply shuts down without any notification 5%

Now, that being said, we still use FoxPro at our company. There are some
things it is really good for like processing & manipulating bulk data.
If I had to use perl or java or whatever to process comma delimited
files or badly maintained excel spreadsheets, I would go nuts. There's
just so many commands for manipulating data that make life much easier.
We then use ODBC to update the "final" versions residing on Postgresql.