From: lindsey@tincup.enet.dec.com (Randy Lindsey)
Subject: Re: Strange FoxPro behavior on Novell 2.15c LAN
Organization: Colorado Software Solutions, Inc.
Date: Sat, 17 Oct 1992 00:07:08 GMT


In article <viking.718690561@vincent2.iastate.edu>, viking@iastate.edu (Dan Sorenson) writes...
>	Note the crossposting!  This seems relevant to both
>groups, and I'm stumped on which is the culprit.
> 
>	I'm running FoxPro/LAN 2.0 on a Novell 2.15c LAN.  We have
>some Apex 286's on a thin-wire Ethernet, each using SMC ethernet
>boards.  Each machine runs DOS 5.0 up high, netx down low, and
>smartdrv.exe with whatever it can get a hold of. (sadly, no EMS
>memory on these, and I haven't gotten QEMM yet)  I run DOS high
>to free up memory, but NETX low due to reports of it being a
>bit unreliable if loaded high.
> 
>	Alright, here's where it gets wierd.  All queries and data
>entry are handled with various .prg files, one acting as a program
>launcher to call others as necessary.  For example, MENU.PRG is
>a simple menu that issues the command "do stats" to run the
>program STATS.PRG, which does some statistical analysis.  The
>menu program then closes all, releases all, and goes back into
>its near-infinite loop.  I did this to avoid having to re-start
>foxpro when done iwth one routine.
> 
>	Today I had to modify an if-else-then conditional, so I
>completed my modification, had the other user exit to MENU,
>compiled it, and had her launch it again.  On my machine, the new
>conditional takes effect.  On hers, it does not.  This is while
>using the same data set!  How is this possible?  MENU.prg was not
>modified, and the program I modified is called by MENU.  I do not
>use the menu program on my workstation, but can this make any
>sort of difference?
> 
>	I've also noticed that I am less often seeing a "Cannot create
>program.fxp" error on the screen.  This usually happens when I modify
>a procedure and attempt to re-compile while somebody else is running the
>program.  Most often, I'll re-compile from my workstation but have
>occassionally just left it as the new program code should be compiled
>again by whatever workstation attempts to run it first.  This last
>has not been happening on a few occassions, leading to two different
>versions of the program being run at the same time.
> 
>	So what can I look for?  This doesn't sound like a FoxPro bug,
>as it's just recently started happening.  My workstations can't
>hold much of these programs in memory, and smartdrv.exe doesn't cache
>the file server-resident programs anyway.  Could it be something to do
>with the Novell cache not being updated quickly enough or time-stamping
>the files with the correct time so Fox can know the source has changed?
>The only hardware changes made recently were the addition of the MENU.prg
>program launcher application, upgrading all machines to DOS 5.0, adding
>the disk cache from Smartdrv.exe, and adding another meg of RAM to the
>286 boxes that all this is happening on.
> 
>	Frankly, I'm stumped, and I can't reliably re-create this
>problem either.  Strangely enough, we've also noticed that on some
>rare occassions a program will be launched but the workstation will
>lock up shortly after launching the next .fxp; we can't re-create
>this either.  All things point to FoxPro being the culprit, but it
>has just started happening and I've not patched anything since it was
>first installed.
> 
>	Oh, Novell support claims it's either Fox or a small gremlin
>in my workstations, fox claims it can't happen, and the workstation
>manufacturer claims that any of the above might cause it.  <grrrrr>
> 
><Dan Sorenson, DoD #1066 |"I see angels on Ariels in leather and>
><z1dan@exnet.iastate.edu | chrome, Swooping down from heaven to >
><viking@iastate.edu      | carry me home."   ---    R. Thompson >
><ISU thinks I need more education, which they provide for a fee.>

I'd try a few things:

1. Run the MENU program on your workstation.  Does it behave like the
other station?  If so, either recompile MENU to make sure it matches the
source code, or check the source for something that makes it call from
a different directory.

2. Make sure you aren't compiling to a different location than you think
you are.  Use DOS 5's DIR program.fxp/s on all drives, especially your
local drives to see.

3. Make sure all workstations are using the same DOS time.  Do TIME at
the DOS prompt.  Workstations can have inaccurate clocks, and it is possible
to attach to Novell servers in a way that doesn't update your DOS time.  That
would account for the timestamp on files disagreeing with the station's
current time, causing it to skip compiling.  Also, make sure SET DEVELOPMENT ON
in FoxPro, or it won't recompile.

Good luck,
Randy
Newsgroups: comp.databases