Mike, > And, not to hijack anyone's thread, but just as a head's up > It may be due to some less-than-mature NIC drivers, but I'm seeing an > annoying habit of Win7 Pro 32 and 64 to drop network > shares....i.e., I > put DBFs on a network share S: drive that is mapped on each > workstation > to \\SERVERNAME\CDRIVE. I can't get it to mess up > consistently, but it > smells like it has to do with inactivity. In other words, if there's > been no access to the share in X minute, the share is dropped > by either > my Linux Samba box, or Win 7. Things will be going along fine and > suddenly an error will pop up > "c:\data\file.dbf" unavailable...abort, retry, ignore" > Nothing seems to help so far other than opening a Windows Explorer > window and accessing the share (which usually shows a red dot on the > drive icon in the folder listing.) After clicking the share, the red > mark turns green and all is well as long as the VFP > application re-tries > the access. > > The frustrating part is that it's totally inconsistent.
I have a similar problem with Inmotion provided MySQL databases: it randomly drops the server connection. I believe what's happening is that the shared (cheapo) MySQL servers are setup to support webpage access, quick in-and-out transactions, verus long running client/server configurations (per a MySQL timeout variable) As a workaround until I have a better MySQL setup, I've somewhat tamed the beast by setting a timer pop in the app that sends a transaction at intervals, currently set to 5 seconds. Not perfect, but the connection doesn't drop as often. (current MySQL apps are for internal stuff only, I wouldn't sell this service to a customer without a better arrangement) Hopefully you'll find the problem. If it does take time to resolve and you need a quick workaround, maybe triggering some activity via a timer pop can help? Bill > > Mike > > > Ted, > > > > After some wrestling with this issue, I've been requiring > customers to > > install into a folder off the root (c:\productname), and > haven't had any > > problems at all (so far) with doing so. Data files are > generally stored in > > subfolders of this folder, with exceptions for large > read-only tables to > > live elsewhere to streamline backups. > > > > > > Bill > > > > > >> I've got a client with a VFP9 SP2 exe I've just installed onto a > >> Windows 7 Pro 32-bit machine. They've got a nice little > installer that > >> I'm sure they spent a bit of time getting right. > >> > >> The problem is that they install into C:\Program Files and have > >> settings DBFs in that directory and data and temp directories under > >> that folder. As an ordinary user of Windows 7, I'm running into > >> permissions problems writing to those files or creating new ones. I > >> suspect this is A Good Thing and it's better to go along > with it than > >> hack at the machine to try to get it to do something it was not > >> designed for. > >> > >> What's the current guidelines on where a VFP executable should be > >> installed, and where should the data be stored? > >> > >> -- > >> Ted Roche > >> Ted Roche& Associates, LLC > >> http://www.tedroche.com > >> [excessive quoting removed by server] _______________________________________________ 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/699273FA49A34181AB898B6E3FB599FC@bills ** 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.
