>>>
>>>It can but data replication simplifies the whole process. The biggest problem that you have to work around with OFFLINE views is that only one user can take a view offline at a time. Rather than coding OFFLINE, USE ONLINE, TABLEUPDATE, and ensuring the DBC is copied as well you just simply choose to synchronize your replica with the server.
>>
>>I can't say much about the replication, as I have not had a need to look at anything like it. But, I can ask you why you would consider moving your data to Access? Are you working with very small tables? I'm sure you are aware of the limitations that Access has with tables. I'm not being biased, Access does have its own purpose and niche, but it was never designed to handle large amounts of data.
>
>My question to this is that even though Access has trouble dealing with large tables it doesn't mean it can't hold large tables. If I am accessing the Access data via ODBC in VFP and VFP is now dealing with the data and not Access, doesn't this problem go away? This way I combine Access97's replication with VFP's data handling.

This problem will not go away as far as I know. Through ODBC, Access' data engine will be used to access Access data. This boils down to the potential amount of data in the system (ie. if it might be large, Access might not be a good idea) and maybe even how large the systems is (ie. # of forms, etc.--> if not too many, maybe developing the whole thing in Access is an idea). Or, it is possible that your idea of using a VFP front-end to an Access database is the best solution. I would say that if it is going to possibly be a large database, just program a could routines that copy the data TO an 'offline' database, and a second routine that copies data FROM an 'offline' database, doing the neccessary checking, etc..

Joe