A bit more info: the client is several states remote and has a separate outsourced IT group that manages the PCs, the network, all that messy stuff. We just have to cope with what they do :)
Good ideas on the mapped drives as UNCs and/or trying the STRTOFILE() thing. I think the timeout thing is a "feature" whereby a server can support more "connected" clients by timing out idle ones: https://support.microsoft.com/en-us/kb/297684 The issue for us isn't so much that the connection times out, as that it is so slow to reconnect that VFP gives up on opening the DBF. I'm wondering if there might be some RETRY, SET REPROCESS or SYS(3052) style config in VFP that would affect this. On Wed, May 6, 2015 at 8:44 AM, Ted Roche <[email protected]> wrote: > Folks: > > We have a small VFP exe that launches as a scheduled tasks, ZAPs a > temp table, checks to see if a table on the network has records, > performs some text manipulation, updates records and exits. Been > working fine for decades on a number of sites. > > One new network config on one client is throwing errors. > > The exe is running on a VM within a larger server. The main server has > the files it accesses, mapped as a U: drive. > > The exe attempts to open a DBF exclusive, ZAP it and then do some > processing that might populate it with records. It's run as part of a > batch process that's initiated by a user RDP'ing into the machine. > It's failing. When we run the .exe manually from the file explorer, we > get an error that "U:\Directory\tablename.dbf" can't be found. If we > select <Ignore>, it attempts the ZAP and brings up a file locator > dialog. If we navigate manually to the file (it correctly opens in > U:\Directory\), select the Exclusive and Open it, the process runs > successfully to completion. > > Running the exe again at that point, and it will work fine without > throwing an error! It's only on the first initiation. > > We're thinking this is a problem with the U: drive mapping timing out > and *something* being needed to get the connection to work. > > We've tried a: > > IF NOT FILE("U:\Directory\Tablename.dbf") > wait timeout 30 > ENDIF > > and the error still happened the same way, so querying with FILE() > doesn't seem to be enough to trigger the reconnection. > > Walking through the process again, we noted a red "X" on the U: drive > in the explorer. Clicking on it clears the red "X" and the process > will work fine from there. > > Does anyone know a programmatic way to clear the red "X" and > re-establish the network connection? I was sure I'd see something in > the mailing list archives on this, but my searches didn't turn up > anything. > > > -- > Ted Roche > Ted Roche & Associates, LLC > http://www.tedroche.com -- Ted Roche Ted Roche & Associates, LLC http://www.tedroche.com _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://mail.leafe.com/mailman/listinfo/profox OT-free version of this list: http://mail.leafe.com/mailman/listinfo/profoxtech Searchable Archive: http://leafe.com/archives/search/profox This message: http://leafe.com/archives/byMID/profox/CACW6n4vPfg=uix7--rzo9blhaprebd4gaopa+ecqghzcboh...@mail.gmail.com ** 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.
