X-Original-To:  novell@suvm, PA_IBBA
Newsgroups: bit.listserv.novell
Date:         Wed, 8 Apr 1992 07:58:00 N
Reply-To:     Novell LAN Interest Group <NOVELL@SUVM.BITNET>
From:         PA_IBBA@HNYKUN51.BITNET
Subject:      re: Foxpro/Novell

On April 8th Christopher S. D'Arrigo writes:

  Hi,
>
>    I'm hoping someon can help me understand what has happened to my
>     Programs I've written in Foxpro.  They were developed and tested
>   Under FoxproLn 1.2 and run without error.  However when I install them
>     On the network, bad things begine to happen.
>
>   1) When the user tries to retrieve a record he is first prompted
>      for the records unique key (in this case its a combination of the date
>      and employee number).  This key is then used as the target key when
>      the database is searched.  For example,
>
>@ 2,2 Get mDate
>        @ 3,2 Get mEmployee
>        Read
>        TargetKey = DToC(mDate)+mEmployee
>        Select Workfile Index Date_Emp
>        Seek TargetKey
>        If Found()
>            Do DisplayRec
>            Do EditRec
>        Else
>            Do AddRec
>        EndIF
>
>      SO the database is searched, if a record with the same key is located
>      then the record is displayed and the user is allowed to edit it.
>      If a correspoonding record is not found,  the system will assume that
>      it is a new record and proceed accordingly.
First you would think that you had upgraded to Fox 2.0 and subsequently you
would make compound indices (the CDX files and use these as the are opened
automatically with your database as opposed to the old IDX's which you have
to open manually. Second you must set the type of date italian etc. which
might not be a problem with the U.S. version but make sure anyway.
Thirdly, the silly one just try recreating on the net... The silly ones
usually work for me. Fourthly, Fox uses tmp files, see where they are
located it might be a case of slow local drive and the network if so
point in the right direction using config.fp Fifthly erase all
foxuser files ie do not copy them from the single user system.
Sixthly, the double DO has me slightly worried as I do not see any
record loking anywhere.
>
>      The problem arises with the fact that the system doesnt always find
>      the record, even when it is there. (I have BROWSEd the file and have
>      seen the record there).  This problem mysteriously disappears when
>      I take it off the Netware Lan.
>
>2)  Another problem that has caused some grief since it was installed on the
>     network is that garbage has somehow gotten into the database  (GASP!)
>     I Deleted and packed the databse removing those records which were
>       destroyed.  I have since removed the application for the network
>     and all is fine, but this is only a short term patch.
Foxpro sets up a cache on the local drive. When it crashes that part of the
database is or could be garbled. As such it is not a programming problem
(a part from the crashing) but just tells you to make a good copy frequently.
Alternatively use get commands and assign variables to m.variables. Thus
avoiding working on the database itself untill you are ready to write your
changes. My suggestion would be to upgrade and rewrite using fox 2's
projectmanager, this has made life extremely easy for me.

Good luck let me know what it was in the end.
Lex Makkus
Dept of Pathology
Univ. Hosp. Nijmegen
The Netherlands
Newsgroups: bit.listserv.novell