I suggest try to change to a real RDBMS and not to use DBFs. I used to deal with DBFs, but I had several headaches due to corrupt data, corrupt indexes, which are not uncommon issues related to using DBFs on a multiuser environment. Since I begun using real RDBMS like SQL Server I never went back. Corrupt data, corrupt indexes, and the like, are a thing of the past.

There are many available options out there like PostGreSQL, Maria DB, Firebird, etc. Among the named RDBMS I suggest you use PostGreSQL which is free and is completely robust. Where I work, they use SQL Server Standard Edition which also very good but you have to pay for it and it is not cheap at all.

Greetings.

>I have access to the computer where they are wanting to serve as the main computer. It just a computer that will server as the holding computer for the data. Not even having a server package installed. Basically a shared computer amongst 4 employees.
>
>That's where conceptually, I was going to put the DBC , on the main computer and have the application installed on the client computers w/o the dbc. Thinking about it out loud (typing). Would I still be able to use remote views for the application data entry etc?
>
>>>Also, give that setup. Would you say having the dbc as part of the application project or it's own project and just install that on the main server? Is there anything out there that would explain how to setup a client server setup with vfp ? and using remote views.
>>
>>No, DBC on every comp is no-no for me. Like I said I prefer using CAs. That is so more flexible.
>>Also I prefer all executables to reside on local computers and the database should be somewhere else.
>>
>>For client -server:
>>From our experience - you just make setup for your executable (NO DB included)
>>When you need to install DB just send it to IT guys of your client.
>>If they do not have such then make sure you have access to the server where you DB will reside and install it their by yourself.