Hi Julie,

Yes -- I have a client where we do exactly this. SQL Server on their network (to which everyone in the office connects) and MSDE on laptops and remote sites that use merge replication to get the info to/from the SQL server.

A cool thing about replication is that the publication from the SQL server can be a subset of the entire data set. In the replication setup you can choose to filter the data on any number of critera. We use the rep field so that each rep only has his/her own data on their laptop when they're on the road. Of course, you could filter on plenty of other things as well -- only orders placed inthe last 2 months, customers whose names start with the letter 'X' or whatever.

The great thing about remote sites using replication is that their response times are instantaneous (local data engine) and even if their (always on) link to the main server goes down, they can continue processing.

As for deciding which data store to access, there are several options. For legacy reasons, the system uses DSNs to access the SQL server. It's simply a matter of changing the target server from "SERVER" (which is the immaginative name of their server) to "(local)" (or "." or whatever the name of their laptop is) in the DSN and everything works the same way. If you are using DSN-less connections and SQLSTRINGCONNECT then you'll just need to have a method for toggling the server name in the connect string.

We dealt with the integer primary keys issue by assigning a range of keys to each engine and using a Stored Procedure to get the next key for any table. There's another Stored Proc on the server that allocates ranges of keys in the Small (100,000) Medium (1,000,000) or Large (10,000,000) range. There seem to be plenty of integers so we're not too worried about running out <g>.

Another point to note is that every table involved in merge replication MUST gave a GUID field in it. It doesn't have to be your primary key, but it must exist. In fact, if you don't have one, the replication wizards will try to create one for you.

The last thing I'd say about this is that there are certainly hidden "gotcha's". Changing the structure of tables or adding tables is not straightforward once you've got replication publications. You need to synchronise, drop the publications and re-publish with the new structure. This is not the easiest thing to coordinate if you have a bunch of people who are not in the office very much. There are also issues with subscriptions timing-out if it's too long since a user synchronised (you can adjust tme-out intervals, it's just something you need to be aware of).

HTH,

Cheers,

Andrew

>Hi all,
>
>
> We have a system written in FoxPro accessing SQL data. We now want to deploy it on laptops for people on the road. I have installed MSDE on the laptop as well as my interface. Now what?
>
>
>
> 1. Do I use DTS to get the data from the Network to the Laptop?
>
> 2. Do I do the same to get the data from the laptop to SQL Server?
>
> 3. The laptop is both the local machine on the road and the
> Network machine in the office. If they are in the office can I
> decide what database (local/network) they work on?
>
>
>
>Thanks......