>>I *strongly* suspect that the main reason that the DBF structure "has zero credibility in the client/server world. . . period" is that tables, and especially indexes, are easily corrupted when something 'unusual' (usually involving power) occurs. That's a dicey problem indeed!
>>But with a Server entity as I am trying to describe, this problem *could* be virtually ELIMINATED - a machine operated by professionals in a secure area with UPS would be responsible for all database read/writes (the VFP server) while client machines would be free to do what they pleased (including pulling the plug). Simple, really. Where's the credibility problem there???
>
>Jim,
>
>I don't understand why you wouldn't just use a product like SQL Server if you need reliability. Trying to create an environment where nothing ever crashes is impossible and even approaching it would be much more expensive than moving to client/server. What crash proof operating system will you run this server on? Call me right away when you find one!
>
>Wouldn't VFP server database look a lot like SQL Server? This whole argument makes no sense to me. If you need a database server, why not just buy a datbase server? When I want to make toast, I use a toaster. I don't ask Microsoft to add toasting capabilities to VFP (although Ken Levy could probably do it with about 18 lines of code).

Let's also consider the fact that SQL Server will finish a transaction when a server reboots from a crash/power failure. This is built into the product requiring no coding from the programmer. Could you even emulate this with VFP?

Jack Mendenhall
Reinsurance Management, Inc.