On 3/17/10 2:38 PM, geoff wrote: > Ive done this a couple times before, but as others have said, it is truly > murderously slow. And in many cases so slow as to be useless. And then add a > second user and suddenly it is almost unworkable with data corruption and > other disasters. Quite simply, don't do it.
Up until a couple messages ago, I was under the impression that he wanted to put a VFP database on the other side of the VPN, which would perform horribly as you say. But apparently it is a MySQL database, which can work reasonably well, even multi-user. Especially if you configure it to read from a local replication slave, and write to the master. I was doing this back in VFP6,7,8 and MySQL 3.51 and 4.x, in 2002-2005 or so, using SPT connections and making the cursors updatable with tableupdate(). Indeed, one of the major reasons for moving away from VFP tables to MySQL was for good remote performance. If you instead define the connections in VFP remote views, *keep that database local*. No reason to share it with other users (there's no actual data in there, just view definitions), and due to VFP defects the database can become corrupt especially with multiple users accessing it. Along with good performance, it can be every bit as secure as banking online. IMO nobody should be using VFP databases for data anymore, given the available robust alternatives. Paul _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/profox OT-free version of this list: http://leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/[email protected] ** All postings, unless explicitly stated otherwise, are the opinions of the author, and do not constitute legal or medical advice. This statement is added to the messages for those lawyers who are too stupid to see the obvious.
