Quote:
... Rather than shifting .mdb data across the wire, personally I would simply use Server 2003's remote desktop connection and merely use the travelling PC as a terminal. AFAIK, you get a bundled 1-user administrator licence for remote desktop. The benefits are that you're reducing the risk of corrupting the .mdb file if your remote connection drops, you are not carrying possibly sensitive data around on a laptop that is easily lost/stolen, everything is taking place on the local server so your remote connection speed just limits your screen updating speed, your remote PC requirements are minimal.....

I read down through the discussion waiting to see someone make the point you make here re: "rather than shifting .mdb data across the wire." And I would say that this is doubly important if, as seems the case, this is a monolithic MS-Access application -- no separation of data and interface. I've never seen folks less happy than some cases of people trying to run monolithic MS-Access apps natively off of a disk far, far away. Separating out data into something like MySQL could improve this, but, for many folks that adds too much complexity relative to scale of what is being done. Remote control (RDP, Terminal services, Citrix) lets you be fairly content with an unmodified LAN-oriented app.

Once your network/VPN bits are sorted out, you might try an A-B comparison. From your remote PC, open the MDB from whatever directory you have shared on box "X". Then run box X from same client via RDP -- opening yoru MDB in that RDP session -- and see if you aren't happier. And no data sloshing around