Hi Denis,

>>>Hmm so strange that before .Net DBF did'nt seem to be that bad.
>>
>>http://www.emsps.com/oldtools/msfox.htm#foxprowin26
>>FoxPro 2.6 for Windows/DOS Connectivity Kit, 3.5" disks only (included in FoxPro Professional version)
>
>I understand that different approaches were suggested but I don't see the mention that those offerings were because of a DBF weakness. I understand that there are different tools for different jobs. But if I recall correctly in those days there was dbase, Clipper and some others. Hmmm All used DBF and they seemed to work all right. At that time <g>

I'm not sure where all the fuss is about. It is well known that DBFs are more susceptible to corruption. The main cause is that if is just a file dragged and written over a network where every application has the full access to the files, whether they are trying to corrupt it or not.
Failing networks, virusses, bugs in accessing drivers (like ODBC) or RDBMS's etc. There is no to very little security to ensure the DBF stays healthy. Even VFP TRANSACTION's are not a perfect solution. When your applications crashes in the middle of a TRANSACTION, you never know what you'll end up with.

The SQL server handles all access to the database, though of course you could write and corrupt the database file via the backdoor, though you can shield the database file itself very easily from 98% of the threats. The fact SQL server does not have to worry about failing networks eliminates about the majority of problems which occur with DBF files. With the backup and transaction log the SQL server ensure the ACID properties of the database to a high point. Of course thing can do wrong whether or not using SQL server (e.g. Fire in the server room ?), but it certainly offers a higher degree of data security. Again DBFs, CDXs, FPTs are just files which are only protected the same way as ordinary files by the OS. But a secure DBMSs needs more than this.

This is not to say that you can't create reliable applications with DBFs, but given the historical facts of ill written applications, index, table and fpt corruptions there is enough fact for IT managers to say that they want SQL server in. Given the trouble I had the last couple of days with an application that corrupted tables (see bug when SETting TABLEVALIDATE to 15) it is hard to draw any other conclusion that reliability and stability is better insured by SQL server.

Walter,