>>Point taken....
>>
>>1st a VFP table is NOT a flat file like a txt file from notepad and your network admin needs to know that.
>
>>Alan
>
>Actually, that is exactally what a dbf file is.
>

Well, BOb, if that is true then it is arguable that a SQL Server 'database' is also!

After all, the only 'real' thing that differentiates a SQL Server database/table is that SQL Server manages it own tables within a big (pre-allocated?) file space. Each table itself is no more than a 'flat file' by extension of your logic. That you can't see it in a directory list is simply a technicality. In fact there is no real difference between a .DBF/CDX combination and a SQL Server table/index combination - they are both effectively ISAM in their internal access method.

My take is that a .DBF is decidedly NOT a "flat file", even though it looks like any other flat file when you look at a directory (folder in new terminology).
First, most VFP tables are a combination of a .DBF and a .CDX and many also have an associated .FPT. A flat file has none of that.
A .DBF has a header that defines/describes the file's content. A flat file does not. A .DBF's header also stores the file's record count (and so a calculable file size). A flat file does not.
Your average flat file is written in one single go, more likely than not to all-contiguous HD space. A .DBF is only very rarely written that way, and especially so in a multi-user application.
Your average flat file allows only a single updater at once while a .DBF is designed for multiple 'simultaneous' user updates. Admittedly this is not a function of the file itself, but is IS a difference.

cheers



>BOb