Desperate for ANY degree of input or suggestion re Error(1)...

[OldxBaser]

I have been totally unable to find any information on this.
This post relates to member 113983's recent post regarding an error of the type "<filename> does not exist" where <filename> is an SCX, PRG, or a defined PROC or FUNC in a PRG.

In a large package comprised of ~200 VFP9 EXEs, many of which are executed from custom menu forms, and many others that are executed from running EXEs, we have experienced the above error type in rare occasions (<.1%).

We have analyzed every PJX and have confirmed that the reported non-existing file does exist in the associated EXE.

Here's a very simplistic scenario:

PJX-A (entrypoint - compiled to PJX-A.EXE)
SCX-A (starting focus)
SCXGOOD.SCX
FRX-A
PRG-A
PRGLIB
PROC-1
PROC-2 (loads modal SCXGOOD.SCX)
PROC-3

PJX-B (compiled to PJX-B.EXE)
SCX-B (initial focus)
SCXGOOD.SCX
FRX-B
PRG-B
PRGLIB
PROC-1
PROC-2 (loads modal SCXGOOD.SCX)
PROC-3

PJX-C (compiled to PJX-C.EXE)
SCX-C
SCXGOOD.SCX
FRX-C
PRG-C
PRGLIB
PROC-1
PROC-2 (loads modal SCXGOOD.SCX)
PROC-3

SCX-A selected action = "DO PJX-B.EXE"
PJX-B.EXE opens with SCX-B.SCX
SCX-B selected action PROC-2( ) which opens SCXGOOD.SCX
RETURN from SCXGOOD ... back to modeless SCX_B
MOUSE FOCUS to SCX_A ... select action "DO PJX_C.EXE"
PJX-C.EXE opens with SCX-C.SCX
SCX-C selects a "DO PRG_C" which prints PRG_C.FRX
SCX-C form releases; PJX_C.EXE closes
FOCUS returns to SCX-A
etc. ...

In over 99.9% of times this style of back-and-forth can go on for hours with never a hiccup (through dozens of EXEs).
BUT ... there have been several occurrences of the "<filename> does not exist", usually referring to a PRG or SCX that is guaranteed to be compiled into the EXE that is currently in control. Usually, we even find that this filename has already been used correctly during the current session.

We have reviewed everything we can find in VFP Helpfiles, MSDN, tech websites and forums, to no avail. Out thoughts keep coming back to the problem somehow being caching-related. The problem is rare enough that it has been difficult to reproduce reliably in the lab, but when we did isolate a specific chained sequence of going back-and-forth, we did resolve that particular sequence using CLEAR PROGRAM.

We do not want to use CLEAR PROGRAM everywhere as the answer because of the degradation caused by dozens of users reloading every EXE repetitively all day long across a network.

I have reviewed everything I could find referring to VFP Compiled Program Buffer, SET CLASSLIB/PROCEDURE, Invocation Stack (or Call Stack), PROGCACHE, VFP sequence in locating classes / procs / functions, and so on.
All references I can find regarding the error(1) simply state that the named file does not exist.

I have searched for any way to be able to see into the program buffer, or to determine the EXE source for any of these components in use or in cache.

Does anybody have ANY experience in this area?
I would greatly appreciate any direction you can offer.

 

[Olaf Doschke]

CLEAR PROGRAM surely and obviously is one solution, having unique names in each EXE would be another one.

In regard to "the degradation caused by dozens of users reloading every EXE repetitively all day long across a network.": Well, don't put an EXE on the network, put a CMD file with an XCOPY there to copy only newer files to local, eg an off C:\Program Files folder called C:\FoxApps, which then in the end starts that EXE. The same goes for Runtimes of course. Only data should be shared.

Bye, Olaf.

 

[Steve Bowman]

I would trap for the spacific error in my errorhandler with a line like

if error####
   clear program
   retry
endif

let the error handler handle other errors in usual fassion but handle this one differently

I also will set a global public variable in startup i.e.

lnSpecialErrorCounter=0

then in my handler

if error####
  if lnSpecialErrorCounter<4
     clear program
     lnSpecialErrorCounter=lnSpecialErrorCounter+1
     retry
  else
    exit
  endif
endif

with the second method i will not get into a infinity loop

this all assumes that you call an error handler with ...

on error do handleMyError with program(), error(), lineno() ...

procedure handleMyError
parameters lcErrorProgram, lnErrorNumber, lnErrorLine ...

if lnErrorNumber=1  && 1 is "filename does not exist"
  code...
endif

Steve Bowman
Independent Technology, Inc.
CA, USA