Sounds like an awful lot of trouble for nothing. If you use correct indexing, and parameterize your requests, I see no reason to keep them separate.

I would recommend not using MSDE in the scenario you describe anyway. From what you have mentioned, you might be pushing the limits of the MSDE database. I would suggest SQL Server - or going back to a VFP database.

>Hi all,
>
>I am creating a project with MSDE database. Several tables on the database are rarely updated (there are about twenty tables). In fact, most of the time those tables only act as look-up tables and may not be updated for weeks or even months. OTOH my apps is going to read (read-only) at least one of those table in most of its tasks. Thus, I am thinking to store those tables in local-native-vfp tables.
>Question:
>1. Considering each of those tables won't exceed 10,000 rows, is it worth the effort to store them in local tables (not to mention the synchronization process)? Or should I just let them reside on the server? The apps will be used by about 15 to 20 users on Ethernet-based LAN. Once or twice a week, there will be a remote user connecting thru a dial-up modem (with the help of PC Anywhere and a dummy workstation).
>2. If it's worth it, anybody got any ideas about:
>a. should I use free tables or tables in dbc container?
>b. the most efficient way to check whether the real tables (the ones on the MSDE) has changed?
>c. how to synchronize those tables such that the user doesn’t feel (or doesn’t experience) a performance degradation?
>
>I am looking forward to hearing from all of you!
>
>TIA,
>Willianto